Стандарты и спецификации: XML: Половина стандарта лучше, чем его отсутствие

Выбор XML в качестве основания для формата вашего файла - это только один шаг к портативности, а не весь путь.

Глубокое заблуждение, распространенное сегодня, - что простое проектирование формата вашего файла в XML, так или иначе, сделает его магически портативным, расширяемым и понятным для других программ. Питер Сибах объясняет, почему при проектировании расширяемого формата файла использование XML - это только часть истории.

Питер Сибах, автор, Независимый

Питер Сибах (Peter Seebach) работает с компьютерами много лет и постепенно приспособился. Хотя он до сих пор не понимает, почему мышку надо чистить так часто.



07.03.2007

XML: Половина стандарта лучше, чем его отсутствие

Стандарт Расширяемого Языка Разметки (XML) задает формат данных, но вопрос о том, какие данные следует сохранять, оставляет совершенно открытым. Формат хранения данных весьма гибок, предусматривая отображение произвольно сложных типов данных.

С точки зрения программиста, спецификации, объясняющей программе, что происходит в XML файле, вполне достаточно, чтобы можно было его проанализировать и подтвердить или не подтвердить его правильность, вполне последовательно и надежно. Однако это не дает гарантии понятности. Зная, что XML файл корректный, не обязательно означает, что определенная программа поймет его. Даже подтверждение, что XML файл содержит определенный тип данных, не обязательно поможет вам написать программу, интерпретирующую эти данные. В конце концов, это не является целью XML!

Стандарт XML во многом похож на спецификацию YACC (генератор синтаксических анализаторов) - программу, которая определяет формат для выражения основных правил, а затем создает анализатор для этих правил. XML файлы могут иметь семантику практически настолько же отличную друг от друга, насколько отличны друг от друга различные языки программирования, разработанные при помощи YACC. Фактически XML это не формат файлов, а платформа для написания форматов.

Это создает интересную разновидность полустандарта. Стандарт XML настолько широк и применим практически для всего, и вполне вероятно, что средства для разработки XML совместимы, однако нет повода ожидать, что все данные, фактически сохраненные в XML файлах, будут совместимы со всем, чем угодно. Циники утверждают, что первичная цель XML - позволить совершенно внутренним данным претендовать на совместимость со стандартом.

XML, SGML и HTML

Спецификация Стандартного Языка Обобщенной Разметки - SGML (ISO 8879:1986) предусматривает создание новых языков разметки. Он чрезвычайно гибок и достаточно сложен. Стандарт XML - это один из таких языков разметки, сам по себе предусматривающий расширяемость; XML является подмножеством SGML и нацелен на производство подмножества языков, которые будет проще согласованно и эффективно анализировать.

HTML - это еще один язык SGML, он оказал некоторое влияние на развитие XML, будучи одним из самых широко используемых и отображаемых языков SGML. Многие люди используют языки, основанные на XML, которые достаточно похожи на HTML, чтобы ввести в заблуждение случайного читателя. (Например, оригинал этого документа сделан в XML формате, который использует тэги <p> и другую разметку, неотличимую от HTML.)

Дополнительные ограничения, наложенные XML, упрощают разработку, не препятствуя созданию гибких описаний документа. XML документы могут быть использованы для всего, начиная от документации для офисного программного обеспечения и заканчивая системным администрированием. Например, Mac OS X использует XML, чтобы замещать старый текстовый формат на файлы "списка свойств", используемые для системных предпочтений и конфигурации. С гибкостью, которая сделала SGML интересным, все в порядке и в XML.

Спецификации XML

Спецификация SGML определенного языка разметки называется Описание Типа Документа, или DTD. Например, спецификация HTML существует как группа SGML DTD, каждое из которых определяет, что именно является или не является допустимым в данной разновидности HTML. Спецификация XML позволяет пользователям создавать свои собственные DTD, с некоторыми ограничениями. Однако различным XML документам не требуется иметь каких-либо общих элементов.

Это поднимает вопрос о различии между корректным XML и допустимым XML. Документ, который подчиняется сугубо синтаксическим требованиям (компоновка знаков больше и меньше и использование сущностей (entities)) XML, корректный вне зависимости от содержащихся в нем сущностей или элементов. "Корректность" не зависит от отдельного DTD, это особенность, которую XML документ может иметь без ссылки на DTD, или даже если документ нарушает данный DTD. Документ, который соответствует описаниям элементов конкретного DTD, называется "допустимым".

Допустимый XML может, в принципе, быть использован определенным приложением, которое владеет данным DTD. Знание того, что файл XML корректный, не столь полезно; это гораздо точнее, чем сказать: "формат наших данных - ASCII", но сталкивается с теми же принципиальными ограничениями. Однако даже допустимый XML файл может быть написан для DTD, который может быть недоступен для пользователей, делая его совершенно бесполезным. Мог бы существовать DTD, под которым следующий элемент XML был бы допустимым:

<zz><y/><x>183af892</x><w/></zz>

Спецификации XML сейчас не всегда выражаются через DTD; Microsoft® предложил новый способ выражения тех же типов понятий, называемый XML Схемами. XML Схема стала стандартом W3C в 2001 году. Сами XML Схемы написаны в XML и предназначены, чтобы разобраться с некоторыми проблемами, которые люди имели с традиционными DTD. Возможно, наиболее значительным является больший простор для определения типов данных и семантического содержания. Например, заданные "даты", которые предписывают порядок таких компонентов, как год месяц и день. XML Схемы дают больше семантического содержания, чем традиционные DTD, помогая заполнить пробел между "допустимым" и "понятным". Они также могут определить дальнейшие ограничения на содержание, такие как приемлемый диапазон для числовых значений.

Так стандарт это или нет?

XML это стандарт. Однако это не означает, что "XML файлы " являются стандартом в том смысле, в котором люди обычно думают о стандарте. Если у вас есть две программы, которые обрабатывают "JPEG файлы", вы в большой степени можете предположить, что их файлы взаимозаменяемы. Для XML это не выполняется. Эта проблема всегда существовала для гибких форматов файлов. Например, очень популярный формат файлов "значения, разделенные запятыми" (SCV), используемый дюжинами электронных таблиц и баз данных, кажется достаточно мобильным. Но что вы можете поместить в колонки? Для таблицы, скажем, имен и адресов, формат SCV достаточно портативен. Но как только вы начинаете включать сюда вычисления, форматы начинают резко расходиться; некоторые электронные таблицы могут экспортировать вычисленные значения, другие могут экспортировать формулы в определенном формате. Механистическое описание формата данных не дает полной картины о представлении данных.

Это серьезная проблема, возникающая с "XML файлами". Просто знание, что что-то является каким-то XML, немного скажет вам о совместимости. Две электронные таблицы, сохраняющие свои данные "как XML", могут не иметь ничего общего в форматах сохранения данных. (Постоянные читатели могут вспомнить ту же проблему, возникающую с IFF файлами - см. Ресурсы.)

В некоторых случаях, существуют стандарты для определенных XML форматов. Два или более производителя могут согласиться на определенный XML DTD (или, как теперь принято, Схему) и прекрасно общаться. Однако, если все вы знаете, что они оба используют "XML,", вы никак не можете узнать, используют ли они общую схему. Ясно, что установление этого жизненно важно.

Вы можете написать плохую программу на любом языке

Одна из вещей, которые большинство программистов со временем усваивают, это что ни один язык, каким бы замечательным он ни был, не может предотвратить написание плохой программы. Некоторые проповедники склоняются к тому, чтобы изображать XML как разрешающий все проблемы относительно формата данных, которые досаждали нам веками. Он их не решает. Я не думаю, что было бы честно обвинять XML за ужасные вещи, созданные с его помощью, но важно понимать, что XML не заменяет процесс разработки.

Мой любимый пример этого - XML файл, на который я случайно наткнулся в конфигурации для стратегической игры. С ранних дней компьютерных стратегических игр многие разработчики предпочли сделать многие параметры подстраиваемыми. (Фактически, первая игра с подстраиваемыми установками, которую я увидел, была Космические Захватчики (Space Invaders) - аналог Heathkit H89 - см. Ресурсы.) Вскоре, они бы просто определили формат файла и позволили вам бездельничать; любая опечатка, конечно, развалит всю программу.

Введите XML. Это тот вид проблем, которые XML призван решать. Достаточно хорошей XML Схемы, и вы сможете сделать нечто подобное:

           <team>
             <name>Editors</name>
             <bonuses>
               <economic>20</economic>
             </bonuses>
           </team>
           <team>
             <name>Critics</name>
             <bonuses>
               <military>20</military>
             </bonuses>
           </team>

Какие бы из возможных подстраиваемых параметров ни были включены одним и тем же способом для каждой группы, новые группы смогут быть добавлены с небольшим усилием. Фактически, по крайней мере, одна игра реализовала тип системы, идентичный приведенному выше, однако, другие разработчики игр пошли в прямо противоположном направлении. Вместо того чтобы рассматривать обобщенную спецификацию бонусов, они решили, что каждая команда будет иметь свой бонус и создали XML словарь, в котором бонус каждой команды был определен отдельно. Вышеприведенный пример был бы записан как:

<editor_economic_bonus>20</editor_economic_bonus>
<critic_military_bonus>20</critic_military_bonus>

Вы не смогли бы добавить новые бонусы, или отбросить существующие (хотя вы могли бы установить их на нулевом уровне). Вы не могли бы добавить критикам экономические бонусы (не знаю, зачем бы это могло кому-нибудь понадобиться). Через широкий набор исключительно своеобразных модификаций и подстроек, каждая была закреплена, так что единственная вещь, оставшаяся в файле переменной, это точная величина конкретного бонуса.

Используемый таким образом, XML служит только для искусственного вздутия показателей сжатия. Это более не расширяемый или хотя бы расширенный формат. Это просто очень сложный способ сказать, что что-то никак не может быть изменено. Такие вещи могут случиться из-за того, что кому-то слишком поздно в процессе разработки сказали, что конфигурация обязательно должна "использовать XML".

Возможно, это самое слабое место XML как спецификации. Так как он настолько обобщен, множество плохого XML производится во имя моды. Простой факт, что что-то является XML, не означает, что оно действительно расширяемое или портативное, и позволять модным словам замещать собой серьезный анализ проекта - это сумасшествие.

На некоторых языках вы можете писать хорошие программы

Несмотря на то, что плохую программу можно написать на любом языке, некоторые языки, кажется, действительно поощряют написание хороших программ. Я долго относился скептически к возможности XML это сделать; XML DocBook - прекрасный язык, но я прекрасно себя чувствовал и с SGML DocBook. Однако, недавний пример убедил меня, что у XML есть потенциал, чтобы осчастливить множество людей.

Этот пример - это формат XML "список свойств", разработанный Apple. Списки свойств - это продуманный пример использования XML. Они предоставляют довольно обобщенный способ хранения данных о предметах. Списки свойств широко используются в Mac OS X для выражения предпочтений и других данных. Каждое приложение может определять точный набор искомых ключей в списке свойств, но общий формат предусматривает ряд преимуществ; например, для сохранения одного свойства в списке свойств достаточно единственной строки Objective-C. В качестве интересного примера можно привести launchd производства Apple (замена классическим программам запуска init, cron и inetd производства UNIX®), который использует списки свойств для описания заданий, со страницей руководства (man page), описывающей конкретные пары ключ/значение, которые она поддерживает.

До недавнего времени, Apple была единственной организацией, использующей этот формат. Однако, в апреле 2006 NetBSD приобрела библиотеку для чтения и написания списков свойств. В интересах эффективности библиотека читает и пишет только достаточное подмножество полного XML для управления списками свойств; она не является полным синтаксическим анализатором XML. Что касается этого способа записи, две реализации не являются полностью совместимыми; однако, стандарт с двумя совершенно независимыми реализациями - это очень полезная вещь.

Правильно используемый, XML способствует использованию абстрактных данных и ясному семантическому маркированию сохраненных данных. Даже нечто настолько простое, как серия пар ключ/значение, выигрывает от согласованной спецификации относительно способа их хранения и упорядочивания. Упорядоченная форма XML может быть использована как способ обмена информацией или ее хранения.

Так стандарт это или нет?

Да. По большей части. Неразбериха, создаваемая людьми, говорящими об "XML" так, как будто достаточно сделать что-то в XML, чтобы оно немедленно стало понятным и портативным для всех программ, в которых "есть XML", является серьезной проблемой, но она не является дефектом спецификации. Модное слово имеет тенденцию использоваться там, где оно на самом деле не подходит. Люди думают об XML как о формате высокоуровневого структурирования данных. В известном смысле это так, но если быть боле точным, это платформа, на которой могут быть построены отдельные структурированные форматы данных. XML предоставляет инструменты, которые вы можете использовать для построения структурированных форматов данных. Те же самые инструменты могут быть использованы для производства невыносимых кошмаров и файлов с данными, которые с тем же успехом могут иметь формат только для записи.

Таким образом, если вы хотите знать, означает ли, если файл имеет формат "XML", что вы с большой вероятностью сможете извлечь из него данные, ответ, вероятно, будет отрицательным, но ваши шансы могут быть выше, чем в случае совершенно частного формата. С другой стороны, это шаг, приближающий вас к портативности и открытости, и он служит хорошей платформой. Во введении, я указал, что XML фактически не является форматом файлов, он является платформой для написания форматов. Большинство проблем, которые люди имеют с XML, являются результатом дефектов не в стандарте, а в ожиданиях пользователей - они думают, что это формат данных, и что достаточно указать, что нечто должно использовать XML достаточно, чтобы гарантировать портативность данных.

Если вы собираетесь задать формат данных, у вас должно быть много денег, чтобы использовать XML в качестве базиса; это станет слишком сложным вопросом для вашего персонала невысокого уровня. Но, пожалуйста, от имени всех людей, которые когда-нибудь увидят вашу программу или ваши файлы, я умоляю вас использовать оставшееся время, чтобы подумать о данных, которые вы пытаетесь сохранить. Это плохой формат файла:

<bytes>ff ff 00 03 [. . .]</bytes>

Конечно, кто-то, может быть, его использует. На самом деле, существуют действительно выдающиеся приложения, в которых механизм хранения равнозначен приведенному выше.

Выбор выразительных имен и отображений для сохраненных данных остается важным, и XML не снимает с вас эту ответственность. Что он делает - так это дает вам инструменты, облегчающие вам создание хорошей программы с меньшими затратами времени на разработку. Используйте их правильно.

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=XML
ArticleID=200363
ArticleTitle=Стандарты и спецификации: XML: Половина стандарта лучше, чем его отсутствие
publish-date=03072007