Трансформация XML документов

и формирующих структуру документа. Для того, чтобы обеспечить проверку

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

производящие такую проверку и называемые верифицирующими. На сегодняшний

день существует два способа контроля правильности XML-документа: DTD -

определения(Document Type Definition) и схемы данных(Semantic Schema). В

отличии от SGML, определение DTD-правил в XML не является необходимостью.

Конструкции языка

Содержимое XML-документа представляет собой набор элементов, секций

CDATA, директив анализатора, комментариев, спецсимволов, текстовых

данных.

Элементы данных

Элемент - это структурная единица XML-документа. Заключая слово rose в в

тэги , мы определяем непустой элемент, называемый

, содержимым которого является rose. В общем случае в качестве

содержимого элементов могут выступать как просто какой-то текст, так и

другие, вложенные, элементы документа, секции CDATA, инструкции по

обработке, комментарии, - т.е. практически любые части XML-документа.

Любой непустой элемент должен состоять из начального, конечного тэгов и

данных, между ними заключенных. Например, следующие фрагменты будут

являться элементами:

rose

Saratov

Набором всех элементов, содержащихся в документе, задается его структура,

и определяются все иерархическое соотношения. Плоская модель данных

превращается с использованием элементов в сложную иерархическую систему с

множеством возможных связей между элементами. Производя в последствии

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

заложенную в его структуру - используя элементы документа. Поиск при

этом, естественно, будет гораздо более эффективен, чем нахождение нужной

последовательности по всему документу. В XML документе, как правило,

определяется хотя бы один элемент, называемый корневым и с него программы-

анализаторы начинают просмотр документа. В некоторых случаях тэги могут

изменять и уточнять семантику тех или иных фрагментов документа, по

разному определяя одну и ту же информацию и тем самым предоставляя

приложению-анализатору этого документа сведения о контексте использования

описываемых данных. Например, прочитав фрагмент Holliwood мы

можем догадаться, что речь в этой части документа идет о городе, а вот во

фрагменте Holliwood - о забегаловке. В случае,

если элемент не имеет содержимого, т.е. нет данных, которые он должен

определять, он называется пустым. Примером пустых элементов в HTML могут

служить такие тэги HTML, как
, , .

Комментарии

Комментариями является любая область данных, заключенная между

последовательностями символов Комментарии пропускаются

анализатором и поэтому при разборе структуры документа в качестве

значащей информации не рассматриваются.

Атрибуты

Если при определении элементов необходимо задать какие-либо

параметры, уточняющие его характеристики, то имеется возможность

использовать атрибуты элемента. Атрибут - это пара "название" =

"значение", которую надо задавать при определении элемента в начальном

тэге. Пример:

#ff08ff

white

или

Ivan Petrov

Специальные символы

Для того, чтобы включить в документ символ, используемый для

определения каких-либо конструкций языка (например, символ угловой

скобки) и не вызвать при этом ошибок в процессе разбора такого документа,

нужно использовать его специальный символьный либо числовой

идентификатор. Например, < , > " или $(десятичная форма

записи),  (шестнадцатеричная) и т.д. Строковые обозначения

спецсимволов могут определяться в XML документе при помощи компонентов

(entity).

Директивы анализатора

Инструкции, предназначенные для анализаторов языка, описываются в

XML документе при помощи специальных тэгов - ;. Программа клиента

использует эти инструкции для управления процессом разбора документа.

Наиболее часто инструкции используются при определении типа документа

(например, ) или создании пространства имен.

CDATA

Чтобы задать область документа, которую при разборе анализатор

будет рассматривать как простой текст, игнорируя любые инструкции и

специальные символы, но, в отличии от комментариев, иметь возможность

использовать их в приложении, необходимо использовать тэги . Внутри этого блока можно помещать любую информацию, которая может

понадобится программе- клиенту для выполнения каких-либо действий (в

область CDATA, можно помещать, например, инструкции JavaScript).

Естественно, надо следить за тем, чтобы в области, ограниченной этими

тэгами не было последовательности символов ]].

3. Моделирование XML-документов

Одним из наиболее сильных свойств XML является возможность

создавать собственные языки разметки, в которых определяются элементы и

атрибуты, наилучшим образом соответствующие инкапсулируемой информации, и

снимаются ограничения, вызываемые малопригодным языком общего назначения.

Однако пока нельзя определить язык формальным образом, ограничить словарь

элементов и атрибутов поддающимся управлению множеством и управлять

грамматикой элементов. Процесс формального определения языка в XML

называется моделированием документов. На сегодняшний день существует два

способа моделирования документов: определения типа документа (DTD),

которые описывают структуру документа с помощью декларативных правил, и

XML Schema, описывающую структуру документа на примере с помощью шаблонов

элементов.

Модель определяет документы, которые можно создать с помощью языка;

или, в рамках терминологии XML, модель документа устанавливает, какие

документы согласуются (conform) с языком. Модель документа отвечает на

такие вопросы, как «Может ли быть заголовок у данного элемента?» или

«Должна ли быть указана цена для этого элемента?» Модель является

документом особого рода, написанным по правилам синтаксиса,

предназначенного для описания языков XML, и явно описывает грамматику и

словарь отдельного языка разметки. Иногда язык, который она описывает,

называют типом документа (document type) или приложением XML (XML

application). С помощью такой модели можно определить, согласуется ли

некоторый документ XML с данным типом документа.

Фактически написанные кем-то документы, называемые экземплярами документа

(document instances), могут согласоваться с языком, описанным в модели

документа или не согласоваться. Согласующиеся документы называют

действительными (valid) в контексте языка; другие документы называют

недействительными (invalid).

Модель документа может быть лишним грузом, если надо сопровождать

лишь один-два документа, но если документов много, а требования к

качеству высоки, ее создание может окупиться. Вот некоторые ситуации, в

которых модель документа в состоянии облегчить жизнь:

? Документы создаются людьми и являются данными для компьютерной

программы. Программы особенно привередливы в отношении форматов данных,

потому что трудно создавать программы, способные справляться с

отклонениями от формата. Ограничив применяемый шаблон предсказуемым

форматом, намного легче писать программы, а вероятность ошибок

уменьшается. Сравнение каждого экземпляра документа с моделью

гарантирует, что вы не столкнетесь с проблемой несоответствия.

? В документе обязательно должны быть поля. Например, в бланке заказа

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

посылку. Применение модели документа обеспечивает присутствие всех

необходимых полей.

? Вы запрашиваете документы у людей, не знакомых с используемым

приложением XML. Так как модель сама является документом, она может быть

открытым ресурсом, доступным для загрузки, ссылок и передачи. Модель

документа может выступать в качестве данных в средах создания

структурированных документов, например, в редакторе XML. В такой

программе редактор может автоматически вставлять необходимые поля и

предлагать разработчику документа списки допустимых групп элементов.

? Разработчику нужна надежная структура для развивающегося языка или

семейства языков. Модель документа предоставляет простой способ создания

стандарта, такого, например, как HTML Version 4.0. Отслеживание новых

версий языка жизненно важно для программ XML, поскольку старые программы

могут оказаться несовместимыми с более новыми версиями языка. Модели

документов можно объединить для создания составных языков. Например,

DocBook использует модель таблиц CALS, а не пытается определить свою.

Конечно, могут быть основания и не использовать модель документов.

Сопровождение модели может оказаться неудобным, особенно в начале, когда

язык подвергается тестированию и дальнейшей разработке. Она может

замедлить обработку, например, если браузеры XML должны загружать модель

документа из сети. Наконец, наличие авторитарной модели, указывающей,

какие элементы можно использовать, а какие – нет, может просто сломать

стиль работы. А, кроме того, нужно потратить силы на то, чтобы

разработать модель или найти готовую, отвечающую потребностям. В конечном

счете, автор сам решает, использовать модель документа или нет: XML

спроектирован так, что позволяет работать в любом случае.

Некоторые модели документов (а именно, DTD) не очень хорошо работают

с пространствами имен(пространства имен являются способом группировки

элементов из различных источников, например, встраивания уравнений MathML

внутрь документов HTML). Это создает проблемы, если DTD стремятся

ограничить применяемые автором элементы предсказуемым конечным

множеством. В настоящий момент исчерпывающего решения этой дилеммы нет.

Невозможно предвидеть все виды пространств имен и объявить их элементы и

атрибуты внутри своего DTD – их может быть бесконечное число.

4. Documents Type Definitions (DTD)

В XML-документах DTD определяет набор действительных элементов,

идентифицирует элементы, которые могут находиться в других элементах, и

определяет действительные атрибуты для каждого из них. Синтаксис DTD

весьма своеобразен и от автора-разработчика требуются дополнительные

усилия при создании таких документов(сложность DTD является одной из

причин того, что использование SGML, требующего определение DTD для

любого документа, не получило столь широкого распространения как,

например, HTML). Как уже отмечалось, в XML использовать DTD не

обязательно - документы, созданные без этих правил, будут правильно

обрабатываться программой-анализатором, если они удовлетворяют основным

требованиям синтаксиса XML. Однако контроль над типами элементов и

корректностью отношений между ними в этом случае будет полностью

возлагаться на автора документа. До тех пор, пока грамматика нашего

нового языка не описана, его может использовать только его автор, и для

этого применять специально разработанное программное обеспечение, а не

универсальные программы-анализаторы. В DTD для XML используются следующие

типы правил: правила для элементов и их атрибутов, описания

категорий(макроопределений), описание форматов бинарных данных. Все они

описывают основные конструкции языка - элементы, атрибуты, символьные

константы внешние файлы бинарных данных. Для того, чтобы использовать DTD

в документе, можно или описать его во внешнем файле и при описании DTD

просто указать ссылку на этот файл или же непосредственно внутри самого

документа выделить область, в которой определить нужные правила. В первом

случае в документе указывается имя файла, содержащего DTD-описания:

...

Внутри же документа DTD- декларации включаются следующим образом:

...

...

]>

...

В том случае, если используются одновременно внутренние и внешние

описания, то программой-анализатором будут сначала рассматриваться

внутренние, т.е. их приоритет выше. При проверке документа XML-процессор в

первую очередь ищет DTD внутри документа. Если правила внутри документа не

определены и не задан атрибут standalone ="yes" , то программа загрузит

указанный внешний файл и правила, находящиеся в нем, будут считаны оттуда.

Если же атрибут standalone имеет значение "yes", то использование внешних

DTD описаний будет запрещено.

Определение элемента

Элемент в DTD определяется с помощью дескриптора !ELEMENT, в котором

указывается название элемента и структура его содержимого. Например, для

элемента можно определить следующее правило:

Ключевое слово ELEMENT указывает, что данной инструкцией будет

описываться элемент XML. Внутри этой инструкции задается название

элемента(coach) и тип его содержимого. В определении элемента мы указываем

сначала название элемента(coach), а затем его модель содержимого -

определяем, какие другие элементы или типы данных могут встречаться внутри

него. В данном случае содержимое элемента name будет определяться при

помощи специального маркера PCDATA( что означает parseable character data -

любая информация, с которой может работать программа-анализатор).

Существует еще две инструкции, определяющие тип содержимого: EMPTY,ANY.

Первая указывает на то, что элемент должен быть пустым(например, ),

вторая - на то, что содержимое элемента специально не описывается.

Последовательность дочерних для текущего элемента объектов задается в виде

списка разделенных запятыми названий элементов. При этом для того, чтобы

указать количество повторений включений этих элементов могут использоваться

символы +,*, ? :

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

определены элементы coach, player и assistant, причем элемент title

является обязательным элементом и может встречаться лишь однажды, элемент

player может встречаться несколько раз, а элемент assistant является

опциональным, т.е. может отсутствовать. В том случае, если существует

несколько возможных вариантов содержимого определяемого элемента, их

следует разделять при помощи символа "|" :

Символ * в этом примере указывает на то, что определяемая

последовательность внутренних элементов может быть повторена несколько раз

или же совсем не использоваться. Если в определении элемента указывается

"смешанное" содержимое, т.е. текстовые данные или набор элементов, то

необходимо сначала указать PCDATA, а затем разделенный символом "|" список

элементов. Пример корректного XML- документа:

]>

...

John

< l_name>Dixon

< player number="1">

< f_name >Jorge

Woods

English

…

Определение атрибутов

Списки атрибутов элемента определяются с помощью ключевого слова

!ATTLIST. Внутри него задаются названия атрибутов, типы их значений и

дополнительные параметры. Например, для элемента могут быть

определены следующие атрибуты:

В данном примере для элемента player определяются три атрибута: number и

type, которые имеют типы ID(идентификатор) и список возможных значений

соответственно. Всего существует шесть возможных типов значений атрибута:

. CDATA - содержимым документа могут быть любые символьные данные

. ID - определяет уникальный идентификатор элемента в документе

. IDREF(IDREFS) - указывает, что значением атрибута должно выступать

название(или несколько таких названий, разделенных пробелами во втором

случае) уникального идентификатора определенного в этом документе

элемента

. ENTITY(ENTITIES - значение атрибута должно быть названием(или списком

названий, если используется ENTITIES) компонента (макроопределения),

определенного в документе

. NMTOKEN (NMTOKENS) - содержимым элемента может быть только одно

отдельное слово(т.е. этот параметр является ограниченным вариантом

CDATA)

. Список допустимых значений - определяется список значений, которые

может иметь данный атрибут.

Также в определении атрибута можно использовать следующие параметры:

. #REQUIRED - определяет обязательный атрибут, который должен быть задан

во всех элементах данного типа

. #IMPLIED - атрибут не является обязательным

. #FIXED "значение" - указывает, что атрибут должен иметь только

указанное значение, однако само определение атрибута не является

обязательным, но в процессе разбора его значение в любом случае будет

передано программе-анализатору

. Значение - задает значение атрибута по умолчанию

Определение компонентов(макроопределений)

Компонент (entity) представляет собой определения, содержимое которых

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

программирования подобные элементы называются макроопределениями. Создаются

DTD-компоненты при помощи инструкции !ENTITY:

Программа-анализатор, просматривая в первую очередь содержимое области

DTD- определений, обработает эту инструкцию и при дальнейшем разборе

документа будет использовать содержимое DTD-компонента в том месте, где

будет встречаться его название. Т.е. теперь в документе мы можем

использовать выражение &hello; , которое будет заменено на строчку "Мы рады

приветствовать Вас"

В общем случае, внутри DTD можно задать три типа макроопределений:

Внутренние макроопределения - предназначены для определения строковой

константы, с их помощью можно организовывать ссылки на часто изменяемую

информацию, делая документ более читабельным. Внутренние компоненты

включаются в документ при помощи амперсанта &

В XML существует пять предустановленных внутренних символьных констант:

. < - символ ""

. & - символ "&"

. ' - символ апострофа "'"

. " - символ двойной кавычки """

Внешние макроопределения - указывают на содержимое внешнего файла, причем

этим содержимым могут быть как текстовые, так и двоичные данные. В первом

случае в месте использования макроса будут вставлены текстовые строки, во

втором - бинарные данные, которые анализатором не рассматриваются и

используются внешними программами

Макроопределения правил - макроопределения параметров могут

использоваться только внутри области DTD и обозначаются специальным

символом %, вставляемым перед названием макроса. При этом содержимое

компонента будет помещено непосредственно в текст DTD-правила

Например, для следующего фрагмента документа:

можно использовать более короткую форму записи:

Макроопределения часто используются для описания параметров в правилах

атрибутов. В этом случае появляется возможность использовать одинаковые

определения атрибутов для различных элементов:

Типизация данных

Довольно часто при создании XML-элемента разработчику требуется

определить, данные какого типа могут использоваться в качестве его

содержимого. Т.е. если мы определяем элемент 10.10.98, то хотим быть уверенными, что в документе в этом месте будет

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

последовательность символов. Используя типизацию данных, можно создавать

элементы, значения которых могут использоваться, например, в качестве

параметров SQL-запросов. Программа клиент в этом случае должна знать, к

какому типу данных относится текущее значение элемента и в случае

соответствия формирует SQL-запрос. Если в качестве программы на стороне

клиента используется верифицирующий XML-процессор, то информацию о типе

можно передавать при помощи специально созданного для этого атрибута

элемента, имеющего соответствующее DTD-определение. В процессе разбора

программа-анализатор передаст значение этого атрибута клиентскому

приложению, которое сможет использовать эту информацию должным образом.

Например, чтобы указать, что содержимое элемента должно быть длинным целым,

можно использовать следующее DTD- определение:

Задав атрибуту значение по умолчанию LONG и определив его как FIXED, мы

позволили тем самым программе-клиенту получить необходимую информацию о

типе содержимого данного элемента, и теперь она может самостоятельно

определить соответствие типа этого содержимого указанному в DTD-

определении.

Пример XML-документа, в котором определяются и используются несколько

элементов с различными типами данных:

...

5

2

32.5

true

18346

100 р. 00 к.

...

Как видно из примера, механизм создания элементов документа при этом

нисколько не изменился. Все необходимая для проверки типов данных

информация заложена в определения элементов внутри блока DTD.

DTD весьма удобный механизм осуществления контроля за содержимым

документа. На сегодняшний день, практически все программы просмотра

документов Интернет используют DTD-правила. Однако это не единственный

способ проверки корректности документа. В настоящий момент в W3 консорциуме

находится на рассмотрении новый стандарт языка описания структуры

документов, называемый схемами данных.

5. Схемы данных

Схемы данных (Schemas) являются альтернативным способом создания правил

построения XML-документов. По сравнению с DTD, схемы обладают более мощными

средствами для определения сложных структур данных, обеспечивают более

понятный способ описания грамматики языка, способны легко модернизироваться

и расширяться. Безусловным достоинством схем является также то, что они

позволяют описывать правила для XML-документа средствами самого же XML.

Однако это не означает, что схемы могут полностью заменить DTD-описания -

этот способ определения грамматики языка используется сейчас практическими

всеми верифицирующими анализаторами XML и, более того, сами схемы, как

обычные XML-элементы, тоже описываются DTD. Но серьезные возможности нового

языка и его относительная простота, безусловно, дают основания утверждать,

что будущий стандарт найдет широкое применение в качестве удобного и

эффективного средства проверки корректности составления документов. В

настоящее время в W3 консорциуме идет работа над первой спецификацией схем

данных. Рассмотрим основные возможности схем данных, попытаемся

использовать их для контроля корректности ранее описываемых XML-документов.

Внешне документы схем не отличаются от обычных документов XML.

Документ размечается при помощи специальных элементов, выполняющих в схемах

роль инструкций. Эти инструкции составляют набор правил, используя которые,

программа-клиент будет делать вывод о том, корректен документ или нет.

Схема данных, например, может выглядеть следующем образом:

Если мы включим приведенные правила внутрь XML-документа, программа-клиент

сможет использовать их для проверки. Т.е. она теперь сможет определить, что

правильным будет являться следующий фрагмент:

John Ree

Peter Loyd

Emil McGeer

Все конструкции языка схем описываются правилами "XML DTD for XML-Data-

Schema".

Область схемы данных

Создавая схемы данных, мы определяем в документе специальный элемент,

; внутри которого содержатся описания правил:

Если использовать отдельное пространство имен, то полный XML-документ,

содержащий в себе схему данных, будет выглядеть следующим образом:

Описание элементов

Для определения класса элемента, к которому в дальнейшем будут применяться

инструкции, описывающие его содержимое и структуру, предназначен

специальный элемент схемы elementType. Название элемента задается атрибутом

id . Все дальнейшие инструкции, которые относятся к описываемому классу,

определяют его внутреннюю структуру и набор допустимых данных, содержатся

внутри блока, заданного тэгами и . При

определении класса элемента, можно также использовать комментарии к нему,

которые заключаются в тэги

Атрибуты элемента

Для того, чтобы в описании элемента определить его атрибуты и описать

свойства этих атрибутов нужно использовать элемент attribute:

…

В данном примере элементу определяется атрибут number, значением

которого может быть любая последовательность разрешенных символов:

Подобно DTD, схемы данных позволяют устанавливать ограничения на значения и

способ использования атрибутов. Для этого в дескрипторе

необходимо использовать параметр atttype. Например, если мы хотим указать,

что значение атрибута должно использоваться программой-анализатором как

уникальный идентификатор, то нам необходимо создать следующее правило:

Если же требуется задать список возможных значений атрибута, то пример

будет выглядеть следующим образом:

Модель содержимого элемента

Под моделью содержимого в схеме данных понимают описание всех допустимых

объектов XML-документа, использование которых внутри данного элемента

является корректным. Модель содержимого определяется инструкциями,

расположенными внутри блока . Вложенные элементы описываются

при помощи инструкции element, в которой параметром type указывается класс

объекта - ссылка на его определение:

Если требуется указать режим использования вложенного элемента, то надо

определить параметр occurs:

Возможные значения этого параметра таковы:

. REQUIRED - элемент должен быть обязательно определен

. OPTIONAL - использование элемента не является обязательным

. ZEROORMORE - вложенный элемент может встречаться несколько раз или ни

разу

. ONEORMORE - элемент должен встречаться хотя бы один раз

Примеры правильных XML-документов, использующих приведенную выше схему:

John Ree

English

Celtics

Portsmut

или

John Ree

Celtics

Portsmut

Кроме элементов, содержимым XML-документа могут также является обычный

текст и области CDATA. Для обозначения типов содержимого текущего элемента

в схемах используются следующие инструкции:

. - указывает на то, что содержимым элемента является только

свободная текстовая информация(секция PCDATA) :

. - указывает на то, что содержимым элемента должны являться

только элементы, без текста, незаключенного ни в один элемент:

. - любое сочетание элементов и текста

. - пустой элемент.

Группировка элементов

Элемент group используется для того, чтобы задать некоторую

последовательность вложенных объектов:

Группировка объектов позволяет определять сразу группу объектов различных

типов, которые могут находится внутри данного объекта. В приведенном

примере мы указали, что внутри объекта типа conteam могут быть включены

элементы title, player, и assistant, причем атрибутом occurs мы указали,

что элементы в группе являются необязательными. Корректным для таких схем

будут являться следующие фрагменты документов:

Celtics

…

…

...

Celtics

...

Celtics

…

При помощи атрибута groupOrder можно также задавать режим использования

группированных элементов При установленном значении OR возможно

использование не всех элементов группы, а лишь некоторых из них. Если

задано значение AND, то оба элемента должны быть включены в обязательном

порядке. Например, для следующей группы правил:

будут считаться правильными только следующие варианты:

Celtics

…

…

или

Celtics

…

Закрытая и открытая модели описания содержимого элемента

Когда мы определяем модель содержимого текущего элемента, список

дополнительных допустимых элементов правилами не ограничивается - он может

свободно расширяться. Например, для приведенного выше правила, кроме

обозначенных элементов , и вполне могут

использоваться дополнительные элементы, неописанные правилами, например,

:

Celtics

…

…

…

Однако в том случае, если мы хотим ограничить создаваемые нами правила от

включения дополнительных элементов, мы должны использовать атрибут content

и установить для него специальное значение CLOSED:

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

т.к. параметром content запрещено использование внутри элемента team других

объектов, кроме указанных в правиле.

Иерархия классов

Для того, чтобы при описании класса ограничить список объектов, которые

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

элемент схемы domain. Инструкция указывает, что текущий объект

должен определяться строго внутри элемента, заданного этим тэгом. Например,

в следующем фрагменте указывается, что элемент может быть

определен строго внутри тэга :

Ограничения на значения

Значения элементов могут быть ограничены при помощи тэгов и ;:

1125

Использование правил из внешних схем

Схема может использовать элементы и атрибуты из других схем. Для этого надо

использовать атрибут href, в котором указывается название внешней схемы.

Например:

Компоненты схем

Компоненты, или макроопределении, используются в схемах точно также, как и

в DTD. Для их определения предназначены тэги и

;:

goalkeeper

Типы данных

В схемах существует возможность задавать тот или иной тип данных, используя

при определении элемента директиву с указанием конкретного типа:

В DTD мы должны были создать атрибут с конкретным названием, определяющим

операцию назначения формата данных, и значением, определенным как fixed.

Использование элемента позволяет указывать это автоматически, но

для обеспечения программной независимости необходимо сначала договориться

об обозначениях типов данных(значения, которые должны передаваться

параметру dt элемента datatype), для чего могут использоваться, например,

универсальные идентификаторы ресурсов URI. В любом случае, как и прежде,

все необходимые действия, связанные с конкретной интерпретацией данных,

содержащихся в документе, осуществляются программой-клиентом и определяются

логикой его работы. В разделе, посвященном DTD, мы уже рассматривали пример

XML-документа, реализующего описанные нами возможности. Вот как выглядел бы

этот пример при использовании схем данных:

...

5

2

32.5

true

18346

34.28

…

...

Подводя итог всему сказанному, необходимо отметить, что процесс развития

современных информационных систем настолько динамичен, что временной

промежуток между появлением новой технологии и ее практическим

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

смену устаревающему стандарту HTML в самое ближайшее время должен будет

прийти новый, более гибкий и универсальный язык описания данных. И тот

факт, что XML как язык еще не стандартизирован и некоторые его составляющие

до сих пор находятся в стадии разработки, видимо, не является причиной

невозможности его использования уже сегодня, для решения конкретных задач в

реальных системах.

Иллюстрационный пример

Файл Clients.dtd

XML документ действительный для этого DTD

John Silver

*********

John Fitzerald Silver

London, Piccadilli st. 467

3458739 p.c. 3487

41

Silver@hotmail.com

172.36.01.12

12.01.03

1290

Arthur Swift

*********

Arthur J. Swift

Dublin. Solar st. 463

65863483 p.c 2342

61

12.02.02

1'000.0$

192.23.41.03

W3C схема эквивалентная предыдущему DTD

Литература:

1. “Изучаем XML” Э. Рей – Спб: Символ-Плюс, 2001.

2. “Мифы и реальности XML” Сергей Кузнецов - ИСП РАН, Центр

информационных технологий.

3. “Semantic Web: роли XML и RDF” С. Деккер – журнал ‘Открытые

системы’ сентябрь 2001

4. Материалы с CIT-forum’a

Конец формы

Страницы: 1, 2