Плюнул на всё и стал отдавать странички в application/xhtml+xml.
Оказалось,
что в браузерах при этом не может работать document.write, так что я
переписал
отвалившуюся ленту закладок с
del.icio.us, по-простому используя
стандартный подход с обновлением DOM-дерева на лету. Заодно разобрался,
наконец, в этом вашем JSON.
Надёжно работает во всех доступных мне браузерах (на Gecko, Webkit, Presto, плюс в рысях).
Языков для «создания» и «описания» изображений достаточно много.
Пробегусь по некоторым из них (это не исследование и не введение в
использование какого-то из них; это teaser слюнявка с линками для
дальнейшего изучения :-)
Упоминаются SVG, DOT, pic, METAPOST, TikZ, Sketch, Context Free Art.
Читать далее11 сентября инфраструктура GRDDL приобрела статус «W3C Recommendation».
Пройдут годы, прежде чем поставщики содержимого начнут уважать GRDDL, однако смысл технологии ясен уже сейчас.
Это мост между существующими диалектами XML и RDF. Использование GRDDL смещает точку приложения усилий с формирования RDF к созданию алгоритмов преобразования существующих данных в RDF (это очень разные вещи). GRDDL как раз обсуждает способы указания возможностей перевода существующих данных в RDF.
Документы могут быть включены в инфраструктуру GRDDL разными путями. В
общем случае для XML для этого нужно объявить пространство имён
grddl и указать в аттрибуте корневого элемента идентификатор ресурса
соответствующего преобразования из XML в RDF (например, файла XSLT).
Механизм также позволяет указывать преобразования для целых классов
XML-документов (имеются в виду классы по профилю или
пространству имён), например, можно указывать преобразования
микроформатов — хаков на HTML — в RDF —
формализованный каркас высокого уровня.
Для определённых типов XML-приложений есть частные особенности
применения, например, «GRDDL-enabling» для HTML-документов включает
указание корректного значения profile в секции метаданных
документа, для XHTML — profile и списка преобразований.
Пример для XHTML (образец из описания GRDDL):
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head profile="http://www.w3.org/2003/g/data-view">
<title>Joe Lambda's Home page [an example of RDF in XHTML]</title>
<link rel="transformation" href="http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokFOAF.xsl" />
<link rel="transformation" href="http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokCC.xsl" />
<link rel="transformation" href="http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokGeoURL.xsl" />
и т. д.
Здесь XHTML-документ и связывается с несколькими преобразованиями (здесь — XSLT), в которых указано, как извлечь данные из XHTML и преобразовать их в набор фактов RDF. Преобразования выполняются по шагам, на каждом шаге результат текущего сливается с уже сформированным RDF; инвариант GRDDL — на выходе получается корректный RDF.
(XHTML-документ обязательно должен быть валидным; создатели невалидных (и уж тем более не well-formed) страниц должны сменить свои убеждения на правильные или быть утилизированы в биореакторе.)
Предполагается, что преобразование в RDF при помощи соглашений GRDDL будут выполнять специальные агенты (например, встроенные в браузеры).
Чем отличается подход GRDDL от текущих решений по извлечению, например, микроформатов при помощи XSLT или как это делает Operator? GRDDL — более обобщённая инфраструктура, не завязанная на определённый формат (в терминах XML — фактически DTD) представления со стороны входных данных. Обобщение и высокий уровень описания, однако, может явиться причиной сложности в реализации GRDDL-агентов и фактическими различиями в деталях их функционирования.
В документе не указывается конкретная технология для извлечения данных:
grddl:transformation attribute whose value is an IRI reference, or list of IRI references, that refer to executable scripts or programs which are expected to transform the source document into RDF.
XSLT представляется одним из удобных (и, что подчёркивается, распространённых) средств извлечения данных из XML, существующие связанные с GRDDL преобразования построены именно на XSLT.
Микроформаты — это хорошо, просто и понятно.
Как можно извлечь микроформатированный контент из документа и сделать с ним миллион классных штук?
Удобно для запросов в XML-документе на извлечение микроформатированного контента использовать выражения XPath.
Читать далееВ общем завершил ядро одной суперсистемки на пыхпыхе. Получилось очень аккуратно, фичасто и компактно. Побил рекорд по размерам index.php:
<?php
require("core.php");
require("base_module.php");
Core::Run();
?>
Теперь я мегакрутой пыхпыхбыдлокодер. Говоря о практическом применении... Я писал это чудо под себя, для своего сайта. Чтобы было удобно расширять и изменять (нынешний движок X-Post хоть и модулен, но имеет слишком большой базовый функционал и слишком низкие уровни абстракции межкомпонентного взаимодействия; шаблонная система - дурацкая и неудобная для меня, почти как в IPB; поддержки i18n нет вообще).
Всё получилось так, как я и задумывал в архитектурном плане; в основе - модули, все модули наследуются от одного класса, что обеспечивает единые интерфейсы для связи ядро-модули, у каждого модуля - свои шаблоны, языковые файлы. Базовый модуль выполнен в виде абстрактного класса. Вообще вся система по полной использует последние возможности PHP 5 в области работы с классами.
Используется много XML (в том числе ради возможности использования DTD для контроля за содержимым), разумеется, с кэшированием... Ядро только работает с модулями, отслеживает зависимости, вызывает стандартные методы модулей, кэширует, что ему подсунешь, обеспечивает несколько методов для парсинга XML, плюс добавление/удаление модулей с учётом зависимостей (хотя это я толком не внедрил пока, только в планах). Информация об установленных модулях и их настройки хранятся в едином XML-файле, что позволяет организовывать различные интерфейсы для управления системой и, опять же, использовать единый механизм доступа к модулям. Славно, легковесно. Это хороший опыт.
Сейчас дилемма: развивать и строить что-то действующее на базе написанной системы или перейти к другим технологиям (но тогда жалко забрасывать написанное).
PHP для меня уже не так интересен.
Думаю, может отдать кому сырец?
Первого-второго в числе прочих дел рисовал пак иконок для одного крупного форума. Это первая моя графическая работа такого масштаба под линухом.
Мутил я всё это дело в SVG — масштабируемом векторном формате графики, впечатления как всегда от SVG прекрасные. Это отличный формат для создания и рисования графических объектов, кнопок, значков, иконок, карт. Его поддержка появляется во всём большем количестве ПО.
Наверное, самое нетривиальное (для меня, во всяком случае) — идеально освоить рисование кривых Безье, но это дело тренировки.
И самое важное — SVG базируется на XML, то есть каждый рисунок представляется собой строго структурированный XML-файл с описанием всех данных рисунка — градиентов, цветов, графических примитивов, путей, что делает SVG высокопортируемым и вообще чрезвычайно удобным для разбора.
Шутка ли, править изображение можно даже не запуская графический редактор. Это очень удобно при однообразном процессинге большого количества картинок — после разработки иконок я решил поправить их прозрачность, не вручную же 48 штук править?
Я написал простейший скриптик, который при помощи sed(1) заменяет в
каждом файле строку opacity:0.85; на opacity:0.8 (тем самым
изменяя прозрачность элемента), и он выполнил всю работу менее чем за
15 секунд — правда эффективно?
Используя XSLT и сложные XML-парсеры можно творить ещё более сложные вещи.
Использование регулярных выражений при "ручной правке" SVG позволяет творить ещё более сложные вещи с минимальными затратами ресурсов.
В общем, рекомендую ознакомиться с SVG, особенно тем, кто интересуется векторной графикой.
Из редакторов советую Inkscape, он под win, lin и mac. Представление о возможностях SVG даёт спецификация SVG 1.1 от W3C.