Консалтинг и автоматизация в области управления
эффективностью банковского бизнеса

Журнал ВРМ World

Хорошо, а что же это такое - этот XML?

Вы уже наверняка слышали об этом. Это не сокращенное обозначение размера одежды "extra medium large". Это что-то, связанное с Web. Это что-то, связанное с метаданными. Но что же это? Расширяемый язык разметки (Extensible Markup Language, XML) - это язык описания документа, используемый, как и Hypertext Markup Language" (HTML), для создания web-страниц. Однако он более универсален, чем HTML, и в целом имеет огромное значение для понимания нами, что такое собственно Web и для чего его можно использовать.

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

Это больше чем HTML

HTML- это язык, используемый для создания web-страниц с помощью серий <тэгов>, указывающих читающей документ программе, в каком виде должен быть представлен этот материал.

Как и HTML, XML является системой тэгов, описывающих компоненты документа. В своем наипростейшем воплощении он может рассматриваться как продвинутая версия HTML. Фактически, это не так: и XML и HTML представляют собой поднаборы некоторых символов, называемых стандартным обобщенным языком разметки (Standard Generalized Markup Language, SGML). Это сложный язык тэгов, который <благодаря своей сложности и сложности необходимых инструментов>, как вежливо замечает Object Management Group, <так и не достиг всеобщего признания> (Object Management Group, Предложение в адрес OMG OA&DTF RFP3: XML-обмен метаданными (XMI): потоковая модель формата обмена (Stream-based Model Interchange Format), стр. 4-33).

HTML состоит из набора заранее определенных <тэгов>, указывающих элементу программного обеспечения, называемому <броузер>, производить с документом определенные действия. Обычно эти тэги описывают аспекты представления, такие как размер и стиль шрифта, расстояние между строками и так далее. Некоторые теги кроме того еще идентифицируют ссылки на другие страницы, рисунки, иллюстрации и тому подобное. Дело в том, что каждый броузер, используемый в Интернете, знает как интерпретировать эти тэги и что с ними делать. Хотя все они в первую очередь относятся к представлению данных, тем не менее, невозможно использовать тэги для описания структуры данных или каким-либо другим образом для описания содержимого некоторого документа. XML позволяет пользователю задавать тэги. Это дает последнему огромные возможности в сфере описания структуры и природы информации, представленной в документе. Но это также означает и то, что стандартные броузеры не смогут работать с этими расширениями. Это делает программную среду для XML такой сложной, как это описано далее. В отличие от HTML, XML не позволяет описывать представление данных. Для этого следует использовать связанный с XML расширяемый язык стиля (Extensible Style Language, XSL).

Что это такое?

Это пример XML, использованного для описания записи данных, которые могут быть представлены в документе:

<?XML version="1.0"?>
<!-- **** Basket **** -->
<PRODUCT>
        <product_id>98756</product_id>
        <product_name>basket</product_name>
        <unit_of_measure>each</unit_of_measure>
        <specification>
                <variable>color</variable>
                <value>blue</value>
        </specification>
        <specification>
                <variable>size</variable>
                <value>large</value>
        </specification>
        <specification></specification>
       <specification/>
</PRODUCT>


Отметьте некоторые интересные особенности этого примера.

В первую очередь, как и в случае с HTML, каждый тэг здесь окружен знаками <меньше чем> и <больше чем> (<>), и обычно сопровождается текстом. За текстом в свою очередь следует концевой тэг в виде </...>. Тэг может не иметь наполнения, и в этом случае либо концевой тэг следует сразу за тэгом (как в <specification></specification>), или тэг сам по себе заканчивается левым слэшем (как в <specification/>). Тем не менее, в отличие от HTML, концевой тэг должен присутствовать всегда.

Второе, что следует отметить - это то, что, в этом случае, за тэгом для следует набор относящихся к нему тэгов, описывающих характеристики (в данном случае - столбцы) продукта. В этом конкретном случае тэг <PRODUCT> был определен таким образом, что предполагалось, что он должен сопровождаться ровно одним тэгом <product_id> и одним <product_name>. Хотя из примера этого и не видно, тем не менее, тэг <unit_of_measure> является необязательным. Тэг <specification> также необязательный, однако таких тэгов может быть несколько.

Хотя это и не обязательно, тем не менее, все XML-документы следует начинать с <?XML version="1.0"?> (указывается соответствующая версия). Заметьте, что структура является иерархической, при этом каждый элемент находится только под одним предшествующим элементом, и в каждом документе существует только одна иерархия.

Комментарии существуют в форме <!-- . . . --> Следует отметить, что двойные дефисы должны быть частью комментария. Кроме того, в отличие от HTML, язык XML позволяет вам использовать комментарий для дезактивации какого-либо фрагмента кода.

Значение тэга задается в <объявлении типа документа> ("document type declaration", DTD). Это тело кода, определяющее тэги через набор элементов ("ELEMENTS").

DTD для приведенного выше примера выглядит так:

<!DOCTYPE PRODUCT [
   <!ELEMENT PRODUCT (product_id, product_name, unit_of_measure?,  specification*)>
   <!ELEMENT product_id (#PCDATA)>
   <!ELEMENT product_name (#PCDATA)>
   <!ELEMENT unit_of_measure (#PCDATA)>
   <!ELEMENT specification (variable, value)>
   <!ELEMENT variable (#PCDATA)>
   <!ELEMENT value (#PCDATA)>
]

DTD для XML-документа может быть частью самого документа, а может и содержаться в некотором внешнем файле. В последнем случае DOCTYPE также будет содержаться в документе вместе с аргументом "SYSTEM -filename-", где "-filename-" - это имя файла, в котором находится DTD. Например, если приведенный выше DTD был во внешнем файле с именем "xxx.dtd", то DOCTYPE будет выглядеть следующим образом:

<!DOCTYPE product SYSTEM xxx.dtd>

Такая же строка затем появилась бы и в качестве первой строки файла xxx.dtd. Заметьте, что имя, определенное в DOCTYPE, должно быть таким же, как имя элемента ELEMENT, находящегося на самом высоком уровне иерархии.

Определение элемента product включает в себя список других элементов, который должен следовать в данном случае за product_id, product_name, unit_of_measure и спецификацией. Знак "?", стоящий после unit_of_measure означает, что он может и не присутствовать в документе. Он является необязательным. Символ "*" после спецификации указывает на то, что она необязательна, но может встречаться один или несколько раз.

Если после какого-либо элемента в списке стоит "+", это означает, что этот элемент обязательный и может встречаться более одного раза.

Каждый из элементов списка по очереди определяется в одной из последующих строк. "#PCDATA" означает, что тэг будет включать в себя текст, который отображается <броузером>. Далее спецификация детализируется пока не дойдет до переменной со значением.

Регистр

XML чувствителен к регистру. Ключевые слова языка XML пишутся исключительно заглавными буквами. Регистр имен тэгов должен быть таким же, как и в их DTD-определени. По соглашению, имена сущностей/таблиц в вышеприведенном примере представлены полностью в верхнем регистре, тогда как имена атрибутов/столбцов - в нижнем. Соглашения могут варьироваться.

Атрибуты

Тэги могут иметь атрибуты.

Например, вместо составления списка ассоциированных тэгов в определении <!ELEMENT specification (variable, value)> (см. выше) в DTD может быть добавлена следующая строка:

<!ATTLIST specification variable CDATA #REQUIRED>
<!ATTLIST specification value CDATA #REQUIRED>


Это создает "variable" и "value" как два атрибута спецификации, таким образом, что они не появляются в качестве полноправных элементов. Данные из приведенного выше примера тогда будут выглядеть так:

<?XML version="1.0"?>
<!-- **** Basket **** -->
<PRODUCT>
        <product_id>98756</product_id>
        <product_name>basket</product_name>
        <unit_of_measure>each</unit_of_measure>
        <specification variable="color" value="blue">
        </specification>
        <specification variable="size" value="large">
        </specification>
        <specification></specification>
        <specification/>
</PRODUCT>


Заметьте, что все это добавляет еще одно дизайнерское решение в актив дизайнера XML. Есть свои преимущества и недостатки в каждом из направлений.

Корректность

С XML-документом связаны три уровня корректности:

  1. "Правильно сформированный" ("Well-formed") XML-документ - это документ, элементы которого соответствующим образом структурированы как дерево с открывающими и закрывающими тэгами на соответствующих местах. Правильно сформированные документы являются необходимой составляющей процесса обмена информацией.
  2. "Корректный" ("valid") XML-документ - это правильно сформированный документ, состоящий из тэгов, связанных с объявлением типа документа (DTD). Он содержит только те значения элементов и атрибутов, которые согласуются с DTD. Хотя XML-документ и может быть подготовлен и прочтен без DTD, DTD необходим для установления его корректности.
  3. "Семантическая корректность" XML-документа лежит вне сферы контроля языка XML. Обязанность эта возлагается на лицо, готовящее документ с тем, чтобы документ безусловно был логически структурирован и не был бессмысленным (там же, стр. 4-36).

Следствия

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

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

К тому же, стандартный броузер по определению не может правильно интерпретировать преобразованные тэги. Эта проблема может быть решена тремя способами:

  1. Могут быть написаны программные апплеты, которые будут подключены к странице. Они будут распознавать структуру данных и реагировать на каждый тэг.
  2. Обычное программное обеспечение может прочитывать DTD и соответственно реагировать на тэги. В этом случае реакция на тэг будет ограничена содержанием считанного из DTD.
  3. Сообщество может определить набор тэгов для своих целей, согласиться использовать их и разработать программное обеспечение специально для данного сообщества, чтобы реагировать на них.
Можно предположить, что первые две опции будут реализованы на Java или сходном с ним языке, но стандартные средства для выполнения остального все равно должны быть написаны. Третья опция только-только начала развиваться. Например, химическая промышленность установила свой основанный на XML Химический язык разметки (Chemical Markup Language). Астрономы, математики и ряд других специалистов также просто определили наборы тэгов для описания необходимого в соответствующих областях науки.

Использование XML для описания данных

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

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

В продолжение описанных выше начинаний химиков и астрономов, Object Management Group (OMG) установила набор XML-тэгов, названный ими XML-обмен Метаданными (XML Meta data Interchange, XMI) в качестве способа описания в стандартных терминах структуры данных о данных (то есть метаданных). Это необходимо для коммуникации между средствами CASE и для описания "хранилища метаданных". В том же направлении некоторая группа компаний находится в процессе определения Общего формата обмена метаданными хранилищ (Common Warehouse Meta data Interchange, CWMI), содержащего поднабор тэгов XMI для поддержки хранилищ данных.

Это означает, что в действительности существует два пути описания структуры базы данных в XML:

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

Заметьте, между прочим, что суть определения хранилища метаданных или коммуникации между средствами CASE заключается не только в использовании XML или любого другого конкретного языка. Суть в структуре базы данных и ее семантике. Важным вопросом остается способ представления универсального хранилища метаданных. Он может быть с легкостью представлен как набором связанных таблиц, так и диаграммой сущностей/отношений. Весь вопрос в том, что там будет содержаться и что это будет означать. XML сам по себе не дает ответа на этот вопрос. Какие объекты являются значимыми и поэтому должны быть описаны? На этот вопрос ответить сложнее. Появление нового языка для их описания, похоже, мало поможет решению этой проблемы.

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

Как говорил Клив Финкелштейн (Clive Finkelstein), пришествие XML ведет нас к тому, что стилисты и дизайнеры данных станут более важными фигурами чем они есть сейчас. "После пятнадцати лет безвестности, стилисты данных возможно будут наконец иметь неожиданный успех" (Клив Финкелштейн, лекция, Ассоциация менеджмента ресурсов данных, Сиэттл, Вашингтон, Май 1993).