Микроформати в контекста на тяхното приложение
Има много спорове около XML за това доколко революционната разширяемост, обещана от разработчиците на XML, ще повлияе (или е засегнала) нас. Наистина ли XML е инструмент за създаване на специализирани езици, предназначени да представят удобно информацията в повечето естествени формати? Или това е просто начин да улесните тези, които пишат код, да се справят с уеб съдържание (бъдете придирчиви към това, което получавате, за да не губите време за глупости). Предоставят ли технологиите на схемите инструментите за контрол на гъвкавостта, която предоставя XML, или са просто друго оръжие срещу потребителите („Невалидно. Отидете“)? Разбира се, начинът ми на задаване на тези въпроси отразява собствените ми убеждения. Вярвам, че XML трябва да бъде инструмент, който внася изразителност и контролирано разнообразие в мрежата. Категорично не съм съгласен с мнението, изразено наскоро в някои тримесечия, че има само няколко жизнеспособни XML формата и че хората трябва да спрат да се опитват да създават нови. Ключов въпрос в този дебат е най-новият акцент в Web 2.0: микроформати. Ако все още не сте запознати с това явление, първо прочетете „Какво представляват микроформатите“.
Този свят е свят на границите
Микроформатите се фокусират върху идеята, че вместо да създават изцяло нови речници, разработчиците трябва да комбинират съществуващи, добре поддържани и широко използвани формати, като XHTML. (В тази статия се съсредоточавам силно върху микроформатите, като XHTML е основният език.) Проблемът е, че XHTML е в най-добрия случай подходящ за описване на основната структура на документ, но в най-лошия случай се използва за подаване на документи . Микроформатите са лесен начин за представяне на по-специализирана информация в XHTML структура без промяна на синтаксиса. Идеята е, че този подход е успешен в случай на скромни (следователно "микро") конструкции в модули, които са взаимно независими и се използват в много специфични области. С тази простота и модулност микроформатите минимизират промените в основните езици, както и опитите за внедряване и повсеместното използване на абстракции.
За съжаление промените рядко се избягват на практика. Много базирани на XHTML микроформати, които съм виждал, прекалено използват XHTML семантиката. Тенденцията е да се злоупотребява по-специално с/@ rel. Препоръката HTML 4.01, чиято семантика е възприета от XHTML, гласи:
Този атрибут описва връзката между този документ и котвата, посочена от атрибута href. Стойността на този атрибут е разделен с интервал списък с референтни типове.
Микроформат като Google rel = 'nofollow' довежда използването на тази дефиниция до абсурд. „Не следвайте тази връзка“ е инструкция към потребителски агент (най-вероятно към автоматизиран агент, например робот за търсене в индекс). Този факт корелира с така нареченото "задействане" в XLink и е много различно от абстрактната връзка между двата документа. Ще побързам да добавя, че микроформатният лагер обикновено е разпознал тези проблеми и че има някои доста разумни случаи на използване на/@ rel в микроформати, включително rel-лиценз и rel-tag. И така, отново се сблъскваме с обвивка на rel, която все още се счита за недовършена, но дава основание да злоупотребяваме с/@ rel без извинение в спецификацията. Злоупотребата с/@ rev в микроформати като глас-връзка е още по-отвратителен пример. И преди да отхвърлите твърденията ми за злоупотреба със съществуващи XHTML конструкции като твърде сложни и несъвместими с реалността, моля, обърнете внимание, че това може да доведе до някои доста сериозни проблеми в случай на конфликт между микроформатите.
Подсъдимият rel, моля, изправете се!
Имате обаче друг инструмент, който търси лични връзки във вашата организация и ги маркира, като използва нотацията "колега" в микроформата XFN.
Един от проблемите е, че ако имате микроформат като XFN, който съзнателно позволява множество маркери в/@ rel, все още могат да възникнат сблъсъци, тъй като не е ясно кои символи са част от XFN и кои са свързани с други конвенции. Това повдига проблема с установяването на граници на собственост между форматите. XFN определя rel = 'date' като изявление, че сте романтично обвързани с лицето, представено от маркера href. Но това може да доведе до известна корелация с микроформата, който описва ресурсите на календара, в който rel = 'date' ще има ясно различно значение.
ГРОЗ. Нямате оправдания.
Друг проблем, произтичащ от ограниченията на основния език, е, че често използвате много объркани и грозни конструкции за бързо коригиране на резултата. Очевидният пример е XOXO. Веднъж направих проучване на XOXO като предпочитан език за обмен на списъци с уеб журнали над основния, макар и доста грозен OPML. В резултат на това завърших с нещо подобно на това, което е показано в Листинг 1.
Листинг 1: Пример за списък с уеблоги на езика XOXO
XHTML не е създаден специално за показване на списъци с източници, така че XOXO е доста масивна добавка към XHTML рамката. Текстът на резултата е обемен и труден за четене. Описвам ужасите на XML, които открих, и един от най-честите примери за абсурд е това, което наричам „заобикаляне на маркирането“. Разработчиците понякога се опитват да игнорират основите, върху които е изградена разширяемостта на XML, и измислят формати, чиято структура е напълно оригинална и всъщност цялата маркировка става съдържание. Често заподозрян е надут превод на CSV файл.