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

Элемент в DTD определяется с помощью дескриптора !ELEMENT, в котором указывается название элемента и структура его содержимого.

Например, для элемента <flower> можно определить следующее правило:

<!ELEMENT flower PCDATA>

Ключевое слово ELEMENT указывает, что данной инструкцией будет описываться элемент XML. Внутри этой инструкции задается название элемента(flower) и тип его содержимого.

В определении элемента мы указываем сначала название элемента(flower), а затем его модель содержимого - определяем, какие другие элементы или типы данных могут встречаться внутри него. В данном случае содержимое элемента flower будет определяться при помощи специального маркера PCDATA( что означает parseable character data - любая информация, с которой может работать программа-анализатор). Существует еще две инструкции, определяющие тип содержимого: EMPTY,ANY. Первая указывает на то, что элемент должен быть пустым(например, <red/>), вторая - на то, что содержимое элемента специально не описывается.

Последовательность дочерних для текущего элемента объектов задается в виде списка разделенных запятыми названий элементов. При этом для того, чтобы указать количество повторений включений этих элементов могут использоваться символы +,*, ? :

<!ELEMENT issue (title, author+, table-of-contents?)>

В этом примере указывается, что внутри элемента <issue> должны быть определены элементы title, author и table-of-contents, причем элемент title является обязательным элементом и может встречаться лишь однажды, элемент author может встречаться несколько раз, а элемент table-of-contents является опциональным, т.е. может отсутствовать. В том случае, если существует несколько возможных вариантов содержимого определяемого элемента, их следует разделять при помощи символа "|" :

<!ELEMENT flower (PCDATA | title )*>

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

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

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

<?xml version="1.0"?> <! DOCTYPE journal [ <!ELEMENT contacts (address, tel+, email?)> <!ELEMENT address (street, appt)> <!ELEMENT street PCDATA> <!ELEMENT appt (PCDATA | EMPTY)*> <!ELEMENT tel PCDATA> <!ELEMENT email PCDATA> ]> ... <contacts> <address> <street>Marks avenue</street> <appt id="4"> </address> <tel>12-12-12</tel> <tel>46-23-62</tel> <email>info@j.com</email> </contacts>

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

Компонент (entity) представляет собой определения, содержимое которых может быть повторно использовано в документе . В других языках программирования подобные элементы называются макроопределениями. Создаются DTD- компоненты при помощи инструкции !ENTITY:

<!ENTITY hello ' Мы рады приветствовать Вас!' >

Программа-анализатор, просматривая в первую очередь содержимое области DTD- определений, обработает эту инструкцию и при дальнейшем разборе документа будет использовать содержимое DTD- компонента в том месте, где будет встречаться его название. Т.е. теперь в документе мы можем использовать выражение &hello; , которое будет заменено на строчку "Мы рады приветствовать Вас"

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

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

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

< - символ "<" > - символ ">" & - символ "&amp" ' - символ апострофа "'" " - символ двойной кавычки """

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

<!ENTITY logotype SYSTEM "/image.gif" NDATA GIF87A>

Макроопределения правил - макроопределения параметров могут использоваться только внутри области DTD и обозначаются специальным символом %, вставляемым перед названием макроса. При этом содержимое компонента будет помещено непосредственно в текст DTD- правила

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

<!ELEMENT name (PCDATA)> <!ELEMENT title (PCDATA | name)*> <!ELEMENT author (PCDATA | name)*> <!ELEMENT article (title, author)*> <!ELEMENT book (title, author)*> <!ELEMENT bookstore (book | article)*> <!ELEMENT bookshelf (book | article)*>

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

<!ELEMENT name (PCDATA)> <! ENTITY %names 'PCDATA | name'> <!ELEMENT article (%names;)*> <!ELEMENT book (%names;)*> <!ENTITY %content 'book | article'> <!ELEMENT bookstore (%content;)*> <!ELEMENT bookshelf (%content;)*>

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

<!ENTITY %itemattr 'id ID #IMPLIED src CDATA'> <!ENTITY %bookattr "ISDN ID #IMPLIED type CDATA'> <!ENTITY %artattr " size CDATA'> <!ELEMENT book (title, author,content)*> <!ATTLIST book %itemattr %bookattr;> <!ELEMENT article (title, author, content)*> <!ATTLIST article %itemattr %artattr;>

Отношения между элементами

Дочерние элементы в XML-документе всегда находятся внутри области, определяемой тэгами родительского по отношению к ним элемента. Для того, чтобы точно указать месторасположение обрабатываемого элемента в дереве XML, в XSL используется дополнительный тэг <element>. При помощи него можно указать, какие элементы должны предшествовать текущему, а какие - следовать после него. Например, в следующем фрагменте определяется, что форматирование элемента <title> будет зависеть от его месторасположения внутри XML-документа:

Как видно из примера, если в XML- документе будет найден элемент <title>, являющийся дочерним по отношению к элементу <article> (название статьи), то его форматирование будет несколько отличаться от элемента <title>, расположенного внутри тэгов <journal>

Перемещение XML в базы данных

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

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

Одна из целей этой статьи и заключается в том, чтобы помочь вам определить оптимальную для себя модель. В этой статье я объясню обе модели хранения: “расщепления” ("shredding") документа (деконструирование XML-файла в реляционные данные и затем оперирование с ними через SQL) и модель хранения большого символьного объекта - Character Large Object (CLOB).

Затем я представлю вам репозиторий Oracle's XML DB и собственный (native) XMLType, которые являются комбинацией этих двух моделей с рядом добавленных возможностей. В идеальном случае, вы получите хорошее представление о той модели хранения, которая наилучшим образом соответствует вашему приложению. (См. врезку.)

Какая модель для каких приложений?

Приложения для XMLType CLOB

Приложения, работающие с документами в целом Web-сайты, приложения управления контентом, архивы документов Приложения, требующие быстрейшей вставки и выборки целых документов Приложения, в которых изменения замещают весь документ Подходящие для документов, описываемых DTD Приложения, требующие памяти для хранения широкого диапазона XML-данных Требуется сохранность/целостность (fidelity) на побайтном уровне Нет требования использовать типы данных Приложения, которые используют поиск в тексте Не требуется доступ через интерфейсы прикладного прогроаммирования (API) XML (DOM, SAX, JAXB).

Приложения для XMLType View

Приложения, работающие с отдельными данными документов Электронный бизнес, интеграция приложений, синхронизация данных, использование данных для других целей Нет требований сохранить XML-документ на побайтном уровне Приложения, использующие XML как мощное средство передачи данных Приложения, требующие широкого использования всех DML-операций Приложения, требующие полного использования оптимизации SQL Приложения, использующие подробный (fine-grained) доступ и изменение данных Приложения, в которых данные из “источника правды” (“source of truth") переинтрепретируются Приложения, поддноживающие множество XML-схем с единой схемой баз данных.

Приложения для XML DB Repository

Приложения, работающие как с документами в целом, так и с их отдельными данными Обработка деловых документов, управление контентп (CM) с поддержкой типов данных, динамическая публикация Приложения, требующие структур хранения для данных, определяемыми схемами, в случае стабильной схемы Приложения, требующие применения как SQL, так и текстового поиска Приложения, использующие ограничения и оптимизации SQL Приложения, требующие подробного (fine-grained) изменения данных Приложения, которым необходимы отношения один-ко-многим в документе Приложения, которые необходимы документы с иерархической организацией.

Практическая работа с XML: опыт безопасного написания документов и приложений

Бенуа Маршаль (Benoit Marchal)
Перевод: Intersoft Lab

Оригинал: Working XML: Safe coding practices

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

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

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

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

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

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

<country><title>Russia</title><city><title>Novosibirsk</country></title></city>

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

На сегодняшний день существует два способа контроля правильности XML- документа: DTD - определения(Document Type Definition) и схемы данных(Semantic Schema). Более подробно об использовании DTD и схемах мы поговорим в следующих разделах. В отличии от SGML, определение DTD- правил в XML не является необходимостью, и это обстоятельство позволяет нам создавать любые XML- документы, не ломая пока голову над весьма непростым синтаксисом DTD.

Правила стилей

В отличие от CSS, в XSL невозможно использование каскадных стилевых определений(т.е. нельзя использовать несколько правил для определения стиля одного того же элемента), т.к. такие ограничения вводит рекурсивный алгоритм работы программы - анализатора. Однако использование правил определения стиля(Style Rules) элемента позволяет каким-то образом скомпенсировать этот недостаток.

Для определения правила стилевого оформления необходимо воспользоваться элементом <style-rule>, который используется точно также, как и <rule>, но инструкции, содержащиеся в нем, никак не влияют на структуру выходного документа. Поэтому все команды внутри этого правила должны описываться в рамках элемента <apply>. Вот как будет выглядеть, например, определение стиля для элемента <flower>rose</flower>:

Если бы мы не определили правила <rule>, то в выходной документ не было бы помещено никакой информации, т.к. элемент <style-rule> только определяет параметры стилевого оформления, не предпринимая никаких других действий.

Также надо учитывать, что XSL- анализатор использует CSS для определения задаваемого правилами <style-rule> стиля в выходном HTML-документе, тем самым предоставляя нам возможность использования этого мощного средства при оформлении HTML-страниц После обработки приведенного в примере фрагмента в выходной документ будут помещены следующие элементы:

Еще один пример:

Стили в формате CSS:

issue {font-weight=bold; color=blue;} .new {font-weight=bold; color=red;}

Фрагмент XSL- документа, позволяющего использовать подобные стилевые определения:

Правила XSL

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

Элементы XML, к которым будет применяться форматирование, обозначаются в XSL дескриптором <target-element/>. Для указания элемента с конкретным названием (название элемента определяется тэгами, его обозначающими), т.е. определения класса элемента, можно использовать атрибут type="<имя_элемента>"

Вот пример простейшего XSL-документа, определяющего форматирование для фрагмента <flower>rose</flower> :

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

Инструкция <target-element> указывает на то, что данное правило определяет элемент. Параметром type="flower" задается название XML-элемента, для которого будет использоваться это правило. Программа-конвертор будет использовать HTML-тэги, помещенные внутри блока <rule></rule> для форматирования XML-элемента, которому "предназначался" текущий блок. В том случае, если для какого-то элемента XML шаблон не определяется, в выходной документ будут добавлены тэги форматирования по умолчанию (например, <DIV></DIV> )

Процесс разбора XSL-правил является рекурсивным, т.е. если у элемента есть дочерние элементы, то программа будет искать определения этих элементов, расположенных "глубже" в дереве документа. Указанием на то, что необходимо повторить процесс разбора XML документа, теперь уже для дочерних элементов, является инструкция <children/>. Дойдя до нее, анализатор выберет из иерархического дерева XML- элементов нужную ветвь и найдет в XSL-шаблонах правила, определяющие форматирование этих нижележащих элементов. В том случае, если вместо <children> мы укажем инструкцию <empty/>, программа закончит движение по данной ветви и возвратится назад, в родительское правило. При этом текущее правило никакой информации в выходном HTML-документе изменять не будет, т.к. <empty/> в данном случае означает, что содержимое элемента отсутствует.

Если в одном правиле <target-element> используется несколько раз, то инструкции по форматированию будут распространены на все описываемые внутри него XML-элементы, т.е. можно задавать единый шаблон форматирования для нескольких элементов одновременно:

<xsl> <rule> <target-element type="item1"/> <target-element type="item2"/> <target-element type="item3"/> <hr> <children/> <hr> </rule> </xsl>

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

XML-документ:

<?XML Version="1.0"?> <documents> <books> <book id="Book1"> <title>Макроэномические показатели экономики Римской Империи в период ее расцвета</title> <author>Иван Петров</author> <date>21.08.98</date> </book> <book id="Book2"> <title>Цветоводство и животноводство. Практические советы</title> <author>Петр Сидоров</author> <date>10.10.98</date> </book> </books> <articles> <article id="Article1"> <author>Петр Иванов</author> <title>Влияние повышения тарифов оплаты за телефон на продолжительность жизни населения</title> <date>12.09.98</date> </article> </articles> </documents>

Содержимое XSL-документа:

<xsl> <rule> <root/> <HTML> <BODY bgcolor="white"> <center><hr width="80%"/><b>Library</b><hr width="80%"/><br/> <table width="80%" border="2"> <children/> </table></center> </BODY> </HTML> </rule> <rule> <element type="book"> <target-element type="author"/> </element> <td align="center"> <p color="red" font-size="14"> <b> <children/> </b></p></td> </rule> <rule> <element type="article"> <target-element type="author"/> </element> <td align="center"> <p color="red" font-size="14" font-style="italic"><children/></p></td> </rule> <rule> <target-element type="book"/> <tr><children/></tr> </rule> <rule> <target-element type="article"/> <tr><children/></tr> </rule> <rule> <target-element/> <td align="center"><p><children/></p></td> </rule> <rule> <target-element type="books"/> <tr><td colspan="3" bgcolor="silver" >Books</td></tr> <children/> </rule> <rule> <target-element type="articles"/> <tr><td colspan="3" bgcolor="silver" >Articles</td></tr> <children/> </rule> </xsl>

Представления типов данных XML

Альтернативой для CLOB XML Type является создание виртуального XML-документа “поверх” набора реляционных таблиц как "XML view." Такой подход позволяет пользователю вставлять, изменять и уничтожать данные в XML-файле таким же образом, как если бы это были SQL-данные. Так как вы определяете виртуальный XML-документ “поверх” структуры хранения данных, то вы не ограничены только одним представлением данных как с CLOB; наоборот, вы можете иметь множество XML-"документов".

Хранение данных в реляционных таблицах также означает, что вы можете изменять отдельные элементы без выборки всего документа. В целом, с XMLType Views вы получите все преимущества и эффективность, связанные с операциями SQL, так как “движок” реляционной базы данных оптимизирован для такого рода выборок. Наконец, вы можете использовать операции SQL с типами данных для обработки типов данных XML вместо интерпретации их как текста. (Например, дата может быть интерпретирована именно как дата с точки зрения SQL, а не как строка симолов.)

Однако, этому подходу присущи некоторые недостатки. Определение XMLType views, в которых уровень вложенности структур велик (то есть, больше 8-10 уровней) может првести к значительной деградации производительности. Вставка и изменение представлений (views) требует применения тирггеров типа instead-of-triggers, и эти операции трудны в сопровождении, так как вы должны включить код приложения в эти тригерры.

Большим преимуществом применения CLOB является полное сохранение структуры документа и гарантия его сохранности на уровне байтов. Но с XMLType View вы теряете гарантию сохранения упорядоченности документа, так как многие элементы (такие как комментарии и инструкции по обработке) исчезнут при размещении (shredding) данных документа в таблицы (базы данных).

Но это все не имеет значения, конечно, если вы размещаете (в базе данных) ваши данные для использования приложениями, ориентированными на работу с отдельными данными (data-centric applications), и для которых не имеет значения структура документа (в целом). Если вам нужно размещать/выбирать данные в/из базы данных и сохранить метаданные нетронутыми (в качестве единственного контекста) и вы хотите воспользоваться все преимуществами операций DML, то применение XMLType Views – это наилучшее решение: Начните со схемы базы данных и сгенерируйте соответствующую XML-схему. В этом случае, следовательно, нет нужды в упорядоченности документа; любая требуемая упорядоченность секций может быть явно определена через ROWIDs или другие специфичные для приложения методы. В состав СУБД и XDK включены функции для создания XML-схем автоматически из XMLType Views.

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

Префиксы

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

Примеры неправильного и правильного кодов приведены в листингах 5 и 6, соответственно.

Листинг 5. Некорректная проверка префиксов

startElement(String uri,String local,String qname,Attributes atts) { if(qname.equals("env:Envelope")) ; // do something }

Листинг 6. Корректная проверка URI пространства имени

startElement(String uri,String local,String qname,Attributes atts) { if(uri.equals("http://psol.com/2005/envelope") && local.equals("Envelope")) ; // do something }

Пример использования

Вот пример использования описанных функций:

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

Встретился новый элемент. В этом случае его название(задаваемое тэгом) доступно при помощи свойства tagName, а содержимое - свойством text. У любого непустого элемента существует хотя бы один потомок, представляющий собой содержимое этого элемента(в этом отличие представленной объектной модели msxml от реальной структуры документа - в XML под элементом понимается как название тэга, так и текстовое содержимое его) Встретилось текстовое поле. Это поле может быть либо комментарием, либо просто текстом, содержащемся в текущем элементе

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

Пример XML-документа

<?xml version="1.0"?> <journal> <title>Very Useful Journal</title> <contacts> <address>sdsds</address> <tel>8-3232-121212</tel> <tel>8-3232-121212</tel> <email>j@j.ru</email> <url>www.j.ru</url> </contacts> <issues-list>

<issue index="2"> <title>XML today</title> <date>12.09.98</date> <about>XML</about> <home-url>www.j.ru/issues/</home-url> <articles>

<article ID="3"> <title>Issue overview</title> <url>/article1</url>

<hotkeys> <hotkey>language</hotkey> <hotkey>marckup</hotkey> <hotkey>hypertext</hotkey> </hotkeys> <article-finished/> </article>

<article> <title>Latest reviews</title> <url>/article2</url> <author ID="3"/> <hotkeys> <hotkey/> </hotkeys> </article>

<author ID="1"> <firstname>Ivan</firstname> <lastname>Petrov</lastname> <email>vanya@r.ru</email> </author>

<author ID="3"> <firstname>Petr</firstname> <lastname>Ivanov</lastname> <email>petr@r.ru</email> </author>

<author ID="4"> <firstname>Sidor</firstname> <lastname>Sidorov</lastname> <email>sidor@r.ru</email> </author> </authors-list> </journal>

Назад | Содержание | Вперед

Пример XSL-документа

<xsl>  <rule> <root/> <HTML><HEAD>  <SCRIPT LANGUAGE="JSCRIPT"><![CDATA[ var ie4=((navigator.appName=="Microsoft Internet Explorer")&&(parseInt(navigator.appVersion) >= 4 )); function msover(){ if (ie4){ event.srcElement.style.color="red"; event.srcElement.style.cursor = "hand"; } } function msout(){ if (ie4){ event.srcElement.style.color="black"; event.srcElement.style.cursor = "auto"; } } ]]></SCRIPT> </HEAD> <BODY bgcolor="white"> <center> <table width="80%" border="1"> <children/> </table></center> </BODY> </HTML> </rule>  <rule> <target-element type="journal"/> <select-elements> <target-element type="title"/> </select-elements>, <select-elements> <target-element type="contacts"/> </select-elements>, <select-elements> <target-element type="issues-list"/> </select-elements>, <select-elements> <target-element type="authors-list"/> </select-elements>. </rule>  <rule> <element type="journal"> <target-element type="title"/>  </element> <tr><td align="center"><center> <table width="80%" border="1"><tr><td width="100%"> <b><font color="blue"> <children/> </font></b></td></tr> </table></center> </td></tr> </rule>  <rule> <element type="journal"> <target-element type="issues-list"/> </element> <tr><td align="center"> <children/> </td></tr> </rule> <rule> <element type="issues-list"> <target-element type="issue"/> </element> <tr><td><center> <table width="100%" border="0"> <tr><td colspan="2" bgcolor="gray"> <font color="white">Issues list</font></td></tr> <children/> <tr><td> </td></tr></table></center></td></tr> </rule> <rule> <target-element type="issue"/> <tr><td> <table width="100%" border="0"> <tr><td colspan="2">Issue number <b><eval>childNumber(this);</eval></b></td></tr> <children/> <tr><td> </td></tr></table></td></tr> </rule> <rule> <element type="issue"> <target-element type="title"/> <target-element type="date"/> <target-element type="about"/> <target-element type="home-url"/> </element> <tr> <td width="40%"><font color="blue"><eval>tagName</eval></font></td> <td width="60%" align="right"><div align="right"><b><font color="red"> <children/></font></b> </div></td></tr> </rule> <rule> <element type="issue"> <target-element type="articles"/> </element> <tr><td colspan="2" align="right" bgcolor="silver"> <center>Articles list</center></td></tr> <children/> </rule> <rule> <element type="articles"> <target-element type="article"/> </element> <tr><td colspan="2" align="right">Article number <b><eval>childNumber(this);</eval></b></td></tr> <children/> </rule> <rule> <element type="article"> <target-element type="title"/> <target-element type="url"/> <target-element type="author"/> </element> <tr> <td width="40%"><font color="maroon"><eval>tagName</eval></font></td> <td width="60%" align="right"><div align="right"><b><font color="red"> <children/></font></b> </div></td></tr> </rule> <rule> <target-element type="article" position="last-of-type"/> <children/> <tr><td colspan="2" bgcolor="silver" width="100%"> </td></tr> </rule> <rule> <element type="hotkeys"> <target-element type="hotkey"/> </element> <tr> <td width="40%"><font color="maroon"><eval>tagName</eval></font></td> <td width="60%" align="right"><div align="right"><b><font color="red"> <children/></font></b> </div></td></tr> </rule>  <rule> <element type="journal"> <target-element type="contacts"/> <select-elements> <target-element type="address"/> </select-elements>, <select-elements> <target-element type="tel"/> </select-elements>, <select-elements> <target-element type="email"/> </select-elements>, <select-elements> <target-element type="url"/> </select-elements>. </element> <tr><td><center><table width="100%" border="1"> <tr><td colspan="2" bgcolor="gray"><font color="white">Contact us:</font></td></tr> <children/> <tr><td> </td></tr></table></center></td></tr> </rule> <rule> <element type="contacts"> <target-element type="address"/> <target-element type="tel"/> <target-element type="email"/> <target-element type="url"/> </element> <tr> <td width="40%"><font color="blue"><eval>tagName</eval></font></td> <td width="60%" align="right"><div align="right"><b><font color="red"> <children/></font></b> </div></td></tr> </rule>  <rule> <element type="journal"> <target-element type="authors-list"/> </element> <tr><td bgcolor="gray"><font color="white">Authors list</font></td></tr> <tr><td> <children/> </td></tr> </rule> <rule> <element type="authors-list"> <target-element type="author"/> <select-elements> <target-element type="firstname"/> </select-elements>, <select-elements> <target-element type="lastname"/> </select-elements>, <select-elements> <target-element type="email"/> </select-elements>. </element> <table width="100%" border="1"> <tr><td colspan="2">Author index <b><eval>getAttribute("ID");</eval></b></td></tr> <children/> <tr><td> </td></tr></table> </rule> <rule> <element type="author"> <attribute name="ID" has-value="yes"/> <target-element type="firstname"/> <target-element type="lastname"/> <target-element type="email"/> </element> <tr> <td width="40%"><font color="blue"><eval>tagName</eval></font></td> <td width="60%" align="right"><b><font color="black">  <DIV id='=tagName + formatNumber(childNumber(this),"1")' background-color="marron" onmouseover='="msover("+ tagName + formatNumber(childNumber(this),1)+")"' onmouseout='="msout("+ tagName + formatNumber(childNumber(this),1)+")"'> <children/> </DIV> </font></b> </td></tr> </rule>  <style-rule> <target-element type="title"/> <target-element type="url"/> <apply font-style="italic" color="maroon"/> </style-rule> </xsl>

Назад | Содержание | Вперед

Приоритеты правил

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

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

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

правила, помеченные специальным тэгом <importance> правила с наибольшим значением атрибута id, если он определен правила с наибольшим значением атрибута class, если он определен правила, имеющие наибольшую вложенность, определяемую тэгом <element> правила, использующие атрибут type совместно с <target-element> правила, в которых отсутствует атрибут type в <target-element> или <element> правила с более высоким приоритетом, задаваемым атрибутом priority тэга <rule> правила с наибольшим значением квалификаторов <only>, <position>, <attribute>

Проблемы кодировки

Более серьезные проблемы могут возникнуть при использовании различных кодировок. Разработчики часто упускают из виду тот факт, что кодировки не ограничивают тот набор символов, который поддерживает XML. Любой документ XML поддерживает полный набор символов Unicode (16- или 32-битные символы в XML 1.1).

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

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

Поскольку переписывание старого приложения редко используется как решение проблемы, необходим способ конвертирования, который превратит символы Unicode в набор, приемлемый для приложения: например, конвертирование i в обычную i (т.е. убирание диакритического знака). Большинство парсеров XML имеют возможности для обработки символов Unicode.

Проблемы пространства имен

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

Пространства имен были введены для управления словарями XML и предотвращения использования тэгов с одинаковыми именами. Часто два словаря могут использовать один и тот же тэг в разных контекстах. Например, в словаре сообщений могут быть тэги для темы, даты, отправителя, адресата и тела письма (см. листинг 2), а в словаре цифровых ресурсов - тэги для темы, даты, описания, камеры и номера кадра (см. листинг 3).

Листинг 2. Словарь сообщений

<envelope> <subject>Test memo</subject> <date>April 26, 2005</date> <from>jack@writeit.com</from> <to>john@xmli.com</to> <body>memo body goes here</body>

</envelope>

Листинг 3. Словарь цифровых ресурсов

<photo> <subject>Westlicht Museum of Camera and Photography, Vienna</subject> <date>April 25, 2005</date> <description>Lobby of the museum</description> <camera>Nikon D70</camera>

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

Пространства имен XML превращают локальные имена в глобальные путем добавления глобального идентификатора к имени тэга. Для того чтобы гарантировать уникальность глобальных идентификаторов, они должны представлять собой URI (Uniform Resource Identifiers - универсальные идентификаторы ресурсов) (т.е. содержать имя домена, зарегистрированного для гарантии уникальности). Соответствующий пример приведен в листинге 4.

Листинг 4. Сочетание словарей

<env:envelope xmlns:env="http://psol.com/2005/env" xmlns:ph="http://psol.com/2005/photo"> <env:subject>Latest photo</env:subject> <env:date>April 27, 2005</env:date> <env:from>jack@writeit.com</env:from> <env:to>john@xmli.com</env:to>

<env:body> <ph:photo> <ph:subject>Westlicht Museum of Camera and Photography, Vienna</ph:subject> <ph:date>April 25, 2005</ph:date> <ph:description>Lobby of the museum</ph:description>

<ph:camera>Nikon D70</ph:camera> <ph:frame>5643</ph:frame> </ph:photo></env:body> </env:envelope>

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

URI - это идентификатор, а не адрес;

префикс - это не идентификатор.

Просмотр XML - документов

Как уже отмечалось, в отличии от HTML, XML никак не определяет способ отображения и использования описываемых с его помощью элементов документа, т.е. программе-анализатору предоставляется возможность самой выбирать нужное оформление. Этого требует принцип независимости определения внутренней структуры документа от способов представления этой информации. Например, задавая в документе элемент <flower>роза</flower>, мы лишь указываем, что rose в данном случае является цветком, но информации о том, как должен выглядеть данный элемент документа на экране клиента и должен ли он отображаться вообще, в таком определении нет.

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

Как уже отмечалось ранее, в общем случае, программы- анализаторы можно разделить на две группы: верифицирующие(т.е. использующие DTD- описания для определения корректности документа) и не верифицирующие. Если Вы создаете свой язык и описываете его грамматику на основе DTD, то для анализа документов, написанных на этом языке, безусловно, потребуется программа, проверяющая корректность составления документа. Но так как использование DTD в XML не является обязательным, то любой правильно оформленный документ может быть распознан и разобран программой, предназначенной для анализа XML- документов. В любом случае, используя универсальные XML- анализаторы, Вы можете быть уверенным в том, что если заданные в документе конструкции языка являются синтаксически правильными, то программа-анализатор сможет правильно извлечь определяемые ими элементы документа и передать их прикладной программе, выполняющей необходимые действия по отображению. Т.е. после разбора документа в большинстве случаев, Вам предоставляется объектная модель, отображающая содержимое Вашего документа, и средства, необходимые для работы с ней (прохода по дереву элементов). При этом в некоторых анализаторах способ представления структуры документа основывается на спецификации DOM, описанной в[]. Поэтому у Вас появляется также возможность использовать строгую иерархическую модель DOM для построения собственных документов.

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

Простой синтаксис

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

Синтаксис XML достаточно простой: просто необходимо соблюдать баланс между открывающими и закрывающими тэгами. Тем не менее автор очень хотел бы получать знаменитый пятицентовик всякий раз получая электронное письмо, отправитель которого сетует на то, что ему не удалось обработать прилагаемый к письму документ XML ни одним из известных ему парсеров. Неизменно при открытии присланного документа XML автор обнаруживает очевидную синтаксическую ошибку - пустой тэг без закрывающей косой черты (например: <empty/>). Если в документе не соблюдаются все правила синтаксиса XML, то он не является документом XML и, значит, не может быть обработан с помощью инструментов XML. Синтаксис XML очень точный и формальный. Все очень просто: либо в документе соблюдаются все правила синтаксиса XML, либо он не может быть распознан как документ XML.

Но некоторые приложения могут отказываться работать с абсолютно точно допустимыми документами. Такие приложения могут реализовывать синтаксис XML не полностью и, соответственно, быть неспособным распознать некоторые символьные сущности (например, i).

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

Решения и исправления

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

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

Если такой тщательный контроль, который обеспечивает парсер, не требуется, то компонент преобразования (такой как JAXB, Castor или Axis) может оказаться удобнее. Эти компоненты напрямую преобразуют тэги XML в объекты JavaTM. JAXB и Castor работают с документами в файлах, а Axis - с web-сервисами. Компоненты преобразования включают парсер XML, поэтому они полностью поддерживают синтаксис XML.

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

Единственная опасность в этом подходе - это то, что нужно корректно передавать зарезервированные символы (см. табл. 1). Особое внимание нужно обращать на символы сущностей (например, i), поскольку они зависят от кодировки документа (см. раздел "Проблемы кодировки" ниже).

Таблица 1. Зарезервированные символы

Символ	Управляющая последовательность	Примечания
<	<
&	&
>	>
'	'	Только в атрибутах, если символ " используется как разделитель
"	"	Только в атрибутах, если символ ' используется как разделитель
другие	&#unicode;	Любой символ, не поддерживаемый данной кодировкой

<
br>
Обычно достаточно простого цикла, аналогичного приведенному в листинге 1. Данную функцию можно применять более эффективно, но листинг 1 синтаксически корректен, если документ создается для потока UTF-8 или UTF-16 (в противном случае необходимо также передать некоторые символы за счет использования символьных сущностей).
Листинг 1. Применение стандартного алгоритма избегания
// assumes UTF-8 or UTF-16 as encoding, public String escape(String content) { StringBuffer buffer = new StringBuffer(); for(int i = 0;i < content.length();i++) { char c = content.charAt(i); if(c == '<') buffer.append("<"); else if(c == '>') buffer.append(">"); else if(c == '&') buffer.append("&"); else if(c == '"') buffer.append("""); else if(c == '\'') buffer.append("'"); else buffer.append(c); } return buffer.toString(); }
Некоторые разработчики предпочитают использовать секции CDATA вместо управляющей последовательности. CDATA - это механизм, который показывает, что часть документа может содержать незаменяемые зарезервированные символы. Например: <condition>< ! [CDATA [a > 4] ] > < / condition>. Этот способ менее надежен, чем управляющая последовательность, т.к. одна секция CDATA не может включать другую такую же секцию.
В качестве еще одного решения автор рекомендует преобразователь (transformer), для чего предлагает познакомиться со своей статьей "Реализация XMLReader" (Implement XMLReader).

Ресурсы

Многоцелевые расширения почтовых сообщений Internet. Часть 2: типы электронной корреспонденции (RFC 2046, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types).

Общественный регистр типов электронной корреспонденции (MIME type registry).

Типы электронной корреспонденции XML (RFC 3023, XML Media Types).

Архитектура всемирной сети, том 1 (Architecture of the World Wide Web, Volume One).

Улучшенный способ идентификации типов файлов, изобретенный фирмой Apple Computer двадцать лет назад. Он также описан в книге "Внутри Macintosh: основы инструментальных панелей" (Inside Macintosh: Macintosh Toolbox Essentials): глава 7 - "Интерфейс поиска" (Finder Interface).

Опыт использования операционной системы BeOS в проекте Haiku.

Библия XML 1.1 (XML 1.1 Bible). Книга также доступна в интернет-магазине Amazon.com.

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

Дополнительные ресурсы по XML на сайте IBM (developerWorks XML zone).

Информация о том, как стать Сертифицированным разработчиком IBM в области XML и других смежных технологий (IBM Certified Developer in XML and related technologies).

С чего начать

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

Рис 1

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

Сценарии

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

Для написания сценариев XSL использует специальный скриптовый язык - ECMAScript. Однако в msxsl для этих целей можно применять Microsoft JavaScript,- язык, который объединил в себе некоторые элементы стандартного JavaScript и ECMAScript.

Схемы

XML Schema and Data Types Preview - http://www.microsoft.com/xml/schema/reference/start.asp

Resource Description Framework
(RDF) Schema Specification - http://www.w3.org/TR/WD-rdf-schema/

Schema for Object-Oriented XML (SOX) - http://www.w3.org/TR/NOTE-SOX/

XML Parsers/Processors - http://www.xmlsoftware.com/parsers/

A Lexical Analyzer for HTML and Basic SGML - http://www.w3.org/MarkUp/SGML/sgml-lex/sgml-lex

UNC Sunsite WWW [and FTP] Server, maintained by W3C XML Chair, Jon Bosak - http://sunsite.unc.edu/pub/sun-info/standards/xml/

XML Editors - http://www.xmlsoftware.com/editors/

Applications development models - http://www.xml.com/xml/pub/Applications

XML.com Guide to Authoring Tools - http://www.xml.com/xml/pub/authortools

Tools - XML and SGML tools including parsers - http://www.xml.com/xml/pub/Tools

Схемы данных

Схемы данных (Schemas) являются альтернативным способом создания правил построения XML-документов. По сравнению с DTD, схемы обладают более мощными средствами для определения сложных структур данных, обеспечивают более понятный способ описания грамматики языка, способны легко модернизироваться и расширяться. Безусловным достоинством схем является также то, что они позволяют описывать правила для XML- документа средствами самого же XML.

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

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

Собственный XML Type

XML DB в СУБД Oracle вводит собственный (native - “родной”) XMLType как объектный тип Oracle и новый, определяемый пользователем, тип данных, который позволяет абстрагироваться от используемой модели хранения. Он предлагает вам как CLOB, так и объектно-реляционное представление “разложенного” (по базе данных) XML-документа. Это единственный, совместимый с XML Schema 1.0 тип, который может использовать команды как SQL, так и SQL-XML с расширенной функциональностью, включая использование встроенных в базу данных PL/SQL и Java.

Этот тип данных XML предоставляет следующие возможности для управления структурами хранения XML:

XPath for XML extraction and updating (XPath для XML извлечения и обновления): Пользователи могут использовать XPath чтобы изменять элементы или атрибуты XML-документов без выборки всего документа. Поддержка XPath предоставляется в форме методов extract() и existsNode() XMLType и выражений Xpath, которые могут быть использованы для навигации по экземпляру XMLType и для поиска по множеству экземпляров XMLType. Oracle также дал расширение SQL (совместимое с появляющимся стандартом SQL-XML), так что пользователи могут специфицировать элементы для запросов (к базе данных) или создавать их через XPath, а затем использовать SQL-операторы с этими элементами. Virtual DOM (Виртуальная DOM): Одной из проблем обработки DOM-моделей заключается в том, что для оперирования с документом весь этот документ должен быть размещен в оперативной памяти как модель объекта, что приводит к увеличению его размеров во много раз. С большими документами это может быть серьезной проблемой. Но XML DB, однако, позволяет пользователям материализовать DOM-модель “на лету” при обработке запросов (виртуальная ("virtual") или ленивая ("lazy") DOM), при этом, чем делая все сразу; деревья данных загружаются по мере того, как они запрашиваются, предварительно загруженные секции документа отбрасываются, если использование оперативной памяти становится чрезмерным. Эта возможность полностью прозрачна. XSL Transformations for XMLType (XSL транформация в XMLType ): Виртуальная DOM-модель особенно полезна при выполнении XSL-преобразований. Как только XSLT-процесс затребует DOM-модель из входного XML-потока, многие пользователи сталкиваются с тем, что документ слишком велик, чтобы завершить этот процесс. Используя виртуальную DOM, однако, пользователи могут обрабатывать только те данные, которые им нужны, отсылать их, фильтровать и получать результаты. Вы можете использовать оператор XML Transform() или метод transform() с любым XMLType. Schema caching (Кэширование схемы): XML DB удерживает структурную информацию (такую, как тэги элементов, типы данных и расположение структур хранения) в кэше схемы, чтобы минимизировать время доступа и расходы на память хранения. Этот кэш расположен на уровне процесса, чтобы минимизировать сетевой трафик и тем самым улучшить производительность при сохранении целостности данных.

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

Следующие шаги

Посетите и сделайте закладки XML Technology Center сети OTN:

http://otn.oracle.com/tech/
xml/content.html

Скачайте Oracle XDK:

http://otn.oracle.com/tech/xml/
xdk/content.html

Прочитайте техническую статью "Oracle XML DB":

http://otn.oracle.com/tech/xml/
xmldb/pdf/xmldb_92twp.pdf

Статьи, спецификации, ссылки на ресурсы

The SGML/XML Web Page - http://www.oasis-open.org/cover/sgml-xml.html

The SGML/XML Web Page - Extensible Markup Language (XML) - http://www.oasis-open.org/cover/xml.html

The SGML/XML Web Page - Extensible Style Language (XSL - http://www.oasis-open.org/cover/xsl.html

The SGML/XML Web Page - Public SGML/XML Software - http://www.oasis-open.org/cover/publicSW.html

he SGML/XML Web Page - SGML/XML Bibliograph - http://www.oasis-open.org/cover/biblio.html

Чего мы ждем от XMLШелли Пауэрс(Мир ПК 3/1998 г.)

- http://www.osp.ru/pcworld/1998/03/180.htm

Overview of SGML Resources - http://www.w3.org/MarkUp/SGML/

XML/XSL Resources - from Bryan Van Hook - http://capita.wustl.edu/XMLRes/

XML News and Links - http://www.arbortext.com/News_and_Events/XML_News_and_Links/xml_news_and_links.html

XML Resources - http://www.microsoft.com/xml/xmllinks.asp

SGML Syntax Summary Table of Contents - http://www.sil.org/htbin/sgml-redirect/sgml/sgmlsyn/contents.htm

XML Community - http://www.inso.com/xml/index.htm

Стилевые таблицы XSL

В предыдущем разделе для вывода элементов XML- документа на экран броузера мы применяли Java Script-сценарии Однако, как уже отмечалось, для этих целей предпочтительней использование специально предназначенного для этого средства - стилевых таблиц XSL(Extensible Stylesheet Language).

Стилевыми таблицами (стилевыми листами) принято называть специальные инструкции, управляющие процессом отображения элемента в окне программы-клиента(например, в окне броузера). Предложенные в качестве рекомендация W3C, каскадные стилевые таблицы(CSS- Cascading Style Sheets []) уже больше года используются Web- разработчиками для оформления Web- страниц. Поддержка CSS наиболее известными на сегодняшний день броузерами Netscape Navigator(начиная с версии 4.0) и Microsoft Explorer(начиная с версии 3.0), позволила использовать стилевые таблицы для решения самого широкого спектра задач - от оформления домашней странички до создания крупного корпоративного Web-узла. Слово каскадные в определении CSS означает возможность объединения отдельных элементов форматирования путем вложенных описаний стиля. Например, атрибуты текста, заданные в тэге <body>, будут распространяться на вложенные тэги до тех пор, пока в них не встретятся стилевые описания, отменяющие или дополняющие текущие параметры. Таким образом, использование таблиц CSS в HTML было весьма эффективно - отпадала необходимость явного задания тэгов форматирования для каждого из элементов документа.

Являясь очень мощным средством оформления HTML- страниц, CSS- таблицы, тем не менее, не могут применяться в XML-документах, т.к. набор тэгов в этом языке не ограничен и использование статических ссылок на форматируемые объекты документа в этом случае невозможно.

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

Некоторые его отличия от CSS:

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

Во-вторых, языком, лежащем в основе XSL, является XML, а это означает, что XSL более гибок, универсален и у разработчиков появляется возможность использования средства для контроля за корректностью составления таких стилевых списков(используя DTD или схемы данных)

В-третьих, таблицы XSL не являются каскадными, подобно CSS, т.к. чрезвычайно сложно обеспечить "каскадируемость" стилевых описаний, или, другими словами, возможность объединения отдельных элементов форматирования путем вложенных описаний стиля, в ситуации, когда структура выходного документа заранее неизвестна и он создается в процессе самого разбора. Однако в XSL существует возможность задавать правила для стилей, при помощи которых можно изменять свойства стилевого оформления, что позволяет использовать довольно сложные приемы форматирования

В настоящий момент язык XSL находится на стадии разработки в W3C[3] и в будущем, видимо, станет частью стандарта XML. Это означает, что использование этого механизма является наиболее перспективным способом оформления XML- документов. В текущем рабочем варианте W3C, XSL рассматривается не только как язык разметки, определяющий стилевые таблицы - в него заложены средства, необходимые для выполнения действий по фильтрации информации, выводимой в окно клиента, поиска элементов, сложного поиска, основанного на зависимостях между элементами и т.д. На сегодняшний день единственным броузером, поддерживающим некоторые из этих возможностей, является бэта-версия Internet Explorer 5.0, однако в самом ближайшем будущем, безусловно, XSL будет использоваться также широко, как сегодня стандартные тэги HTML

В этом разделе мы рассмотрим упрощенную объектную модель XSL- документа, используемую в текущей версии XSL-конвертора Microsoft msxsl, и поэтому информацию, изложенную далее, нельзя считать описанием стандарта языка. Полный рабочий вариант спецификации XSL в последней его редакции доступен на сервере [].

Все примеры, приводимые далее, могут быть проверены при помощи XSL- конвертора, свободно доступного на странице Mcrosoft [ ]

Структура XSL- таблиц

Рассмотрим основные структурные элементы XSL, используемые, в частности, в конверторе msxsl, для создания оформления XML-документов.

Свойства и методы документа(объект XML Document)

URL

root

charset

version

doctype

createElement()

fileSize

fileModifiedDate

fileUpdatedDate

mimeType

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

Возвращает корневой элемент XML- документа

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

Возвращает номер версии XML

Возвращает содержимое элемента !DOCTYPE

Метод, позволяющий создать новый элемент, который будет добавлен в качестве дочернего для текущего элемента дерева. В качестве первого параметра задается тип элемента, в качестве второго - название элемента
xml.createElement(0,"new_element")

Возвращает размер XML- документа. Это свойство в C++- версии анализатора еще не реализовано

Возвращает дату последнего изменения XML- документа. Это свойство в C++- версии анализатора еще не реализовано

Возвращает дату последнего обновления XML- документа. Это свойство в C++- версии анализатора еще не реализовано

Возвращает MIME-тип(MIME- Multipurpose Internet Mail Extension, RFC 1341).Это свойство в C++- версии анализатора еще не реализовано

Ниже приведен фрагмент JavaScript- сценария, использующего эти методы и свойства для вывода информации о текущем документе:

var xmldoc = new ActiveXObject("msxml"); var xmlsrc = "http://localhost/xml/journal.xml"; xmldoc.URL = xmlsrc; function viewProperties(){ this.document.writeln('<center><table width=90% >'); this.document.writeln('<tr>'); this.document.writeln('<td align="center" bgcolor="silver">Document URL</td> <td align="center">'+xmldoc.URL+'</td></tr>'); this.document.writeln('<tr>'); this.document.writeln('<td align="center" bgcolor="silver">Document root</td> <td align="center">'+xmldoc.root+'</td></tr>'); this.document.writeln('<tr>'); this.document.writeln('<td align="center" bgcolor="silver">Document doctype</td> <td align="center">'+xmldoc.doctype+'</td></tr>'); this.document.writeln('<tr>'); this.document.writeln('<td align="center" bgcolor="silver">Document version</td> <td align="center">'+xmldoc.version+'</td></tr>'); this.document.writeln('<tr>'); this.document.writeln('<td align="center" bgcolor="silver">Document charset</td> <td align="center">'+xmldoc.charset+'</td></tr>'); this.document.writeln('</table></center>'); }

Свойства и методы элементов документа

type

tagName

text

AddChild()

removeChild()

parent

GetAttribute()

SetAttribute()

removeAttribute()

children

Возвращает тип элемента. Это свойство может быть использовано для того, чтобы разделить имена тэгов и данные, содержащиеся внутри них. В данной версии анализатора определены следующие типы элементов:
0 - элемент
1 - текст
2 - комментарий
3 - Document
4 - DTD

Возвращает или устанавливает название тэга(в виде строки с символами, приведенными к верхнему регистру). Названия метатэгов(например, <?xml?>) начинаются с символа ?. Названия тэгов комментариев начинаются с символа !.

Возвращает текстовое содержимое элементов и комментариев.

Добавление нового дочернего элемента и всех его потомков в текущую ветвь дерева. В качестве первого параметра этой функции необходимо передать объект типа Element, который затем будет помещен в список дочерних элементов. Также необходимо задать индекс нового элемента в списке и в качестве последнего параметра обязательно передать значение -1. Т.к. в данной модели любой элемент в документе может иметь ссылку только на один родительский элемент, при выполнении данной процедуры у добавляемого объекта старая ссылка на родительский элемент теряется. Используя это свойство, можно перемещать элементы из одного XML- документа в другое, но том случае, если у дочерних ссылок перемещаемого элемента существуют внешние ссылки или сами дочерние элементы ссылаются на внешние возможно возникновение ошибки
elem.addChild(elem.children.item().children.item(0),0,-1)

Удаляет дочерний элемент и всех его потомков. Элементы остаются в памяти и могут быть вновь добавлены к дереву при помощи метода addChild().
elem.removeChild(elem.children.item(1))

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

Возвращает значение указанного атрибута в виде текстовой строки.
elem.getAttribute("color")

Устанавливает указанный атрибут и его значение. Прежнее значение атрибута теряется
elem.setAttribute("color","red")

Уничтожает указанный атрибут
elem.removeAttribute("color")

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

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

Довольно часто при создании XML- элемента разработчику требуется определить, данные какого типа могут использоваться в качестве его содержимого. Т.е. если мы определяем элемент <last-modified>10.10.98</last-modified>, то хотим быть уверенными, что в документе в этом месте будет находиться строка, представляющая собой дату, а не число или произвольную последовательность символов. Используя типизацию данных, можно создавать элементы, значения которых могут использоваться, например, в качестве параметров SQL- запросов. Программа клиент в этом случае должна знать, к какому типу данных относится текущее значение элемента и в случае соответствия формирует SQL-запрос.

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

<!ELEMENT counter (PCDATA)> <!ATTLIST counter data_long CDATA #FIXED "LONG">

Задав атрибуту значение по умолчанию LONG и определив его как FIXED, мы позволили тем самым программе-клиенту получить необходимую информацию о типе содержимого данного элемента, и теперь она может самостоятельно определить соответствие типа этого содержимого указанному в DTD- определении .

Вот пример XML- документа, в котором определяются и используются несколько элементов с различными типами данных:

<!ELEMENT price (PCDATA)> <!ATTLIST price data_currency CDATA #FIXED "CURRENCY"> <!ELEMENT rooms_num (PCDATA)> <!ATTLIST rooms_num data_byte CDATA #FIXED "BYTE"> <!ELEMENT floor (PCDATA)> <!ATTLIST floor data_byte CDATA #FIXED "INTEGER"> <!ELEMENT living_space (PCDATA)> <!ATTLIST living_space data_float CDATA #FIXED "FLOAT"> <!ELEMENT counter (PCDATA)> <!ATTLIST counter data_long CDATA #FIXED "LONG"> <!ELEMENT is_tel (PCDATA)> <!ATTLIST is_tel data_bool CDATA #FIXED "BOOL"> <!ELEMENT house (rooms_num, floor,living_space, is_tel, counter, price)> <!ATTLIST house id ID #REQUIED> ... <house id="0"> <rooms_num>5</rooms_num> <floor>2</floor> <living_space>32.5</living_space> <is_tel>true</is_tel> <counter>18346</counter> <price>34 р. 28 к.</price> </house> ...

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

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

Назад | Содержание | Вперед

Типы данных

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

В DTD мы должны были создать атрибут с конкретным названием, определяющим операцию назначения формата данных, и значением, определенным как fixed .Использование элемента <datatype> позволяет указывать это автоматически, но для обеспечения программной независимости необходимо сначала договориться об обозначениях типов данных(значения, которые должны передаваться параметру dt элемента dataype), для чего могут использоваться, например, универсальные идентификаторы ресурсов URI. В любом случае, как и прежде, все необходимые действия, связанные с конкретной интерпретацией данных, содержащихся в документе, осуществляются программой-клиентом и определяются логикой его работы. В разделе, посвященном DTD, мы уже рассматривали пример XML- документа, реализующего описанные нами возможности. Вот как выглядел бы этот пример при использовании схем данных:

<schema id="someschema"> <elementType id="#rooms_num"> <string/> <datatype dt="int"> </schema> <elementType id="#floor"> <string/> <datatype dt="int"> </schema> <elementType id="#living_space"> <string/> <datatype dt="float"> </schema> <elementType id="#is_tel"> <string/> <datatype dt="boolean"> </schema> <elementType id="#counter"> <string/> <datatype dt="float"> </schema> <elementType id="#price"> <string/> <datatype dt="float"> </schema> <elementType id="#comments"> <string/> <datatype dt="string"> </schema> <elementType id="#house"> <element type="#rooms_num" occurs="ONEORMORE"/> <element type="#floor" occurs="ONEORMORE"/> <element type="#living_space" occurs="ONEORMORE"/> <element type="#is_tel" occurs="OPTIONAL"/> <element type="#counter" occurs="ONEORMORE"/> <element type="#price" occurs="ONEORMORE"/> <element type="#comments" occurs="OPTIONAL"/> </elementType> </schema> ... <house id="0"> <rooms_num>5</rooms_num> <floor>2</floor> <living_space>32.5</living_space> <is_tel>true</is_tel> <counter>18346</counter> <price>34.28</price> <comments>С видом на cеверный полюс</comments> </house> ...

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

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

Типы электронной корреспонденции

При передаче файла web-сервер посылает не только его имя и содержание. Он также отправляет множество метаданных о файле в заголовке HTTP (см. листинг 1):

Листинг 1. Пример метаданных

HTTP/1.1 200 OK Date: Sun, 23 Jan 2005 18:21:33 GMT Server: Apache/2.0.52 (Unix) mod_ssl/2.0.52 OpenSSL/0.9.7d Last-Modified: Sun, 10 Oct 2004 16:17:21 GMT ETag: "3e06d-16a05-2dbc8640" Accept-Ranges: bytes Content-Length: 92677 Content-Type: application/xhtml+xml

Необходимо обратить внимание на заголовок Content-Type в последней строке. Его значение - application/xhtml+xml - это тип электронной корреспонденции (он может сопровождаться информацией о наборе символов документа). Web-браузеры и другие получатели используют эти метаданные для того, чтобы понять, как обрабатывать файл. Например, такие данные позволяют определить, может ли файл быть представлен в своем оригинальном виде или необходимо использовать вспомогательное приложение. Типы электронной корреспонденции используются и в других контекстах, в том числе в электронной почте, а также в некоторых экспериментальных операционных системах, например, BeOS. Linux и другие системы UNIXR также пользуются типами электронной корреспонденции, но делают это несколько по-другому. Они не присваивают файлам напрямую определенные типы электронной корреспонденции, а преобразуют ("мэппируют") расширения файлов в эти типы. Основная область практического использования типов электронной корреспонденции - это интернет.

Основной тип содержимого для типичного документа XML - application/xml. Тип text/xml также является зарегистрированным, но он подвергнулся осуждению из-за некоторых неудачных взаимодействий с другими частями протокола HTTP. (Использование text/xml указывает, что документ находится в кодировке ASCII, даже если декларация XML дает другую информацию). Ниже приведены еще несколько основных зарегистрированных типов электронной корреспонденции:

application/xml-dtd - используется для определения типа документа;

application/xml-external-parsed-entity - используется для фрагментов документов.

По существующему соглашению, для более специфических типов форматов XML используется тип application/foo+xml, где foo подразумевает употребление специального словаря XML. Например, application/rdf+xml для RDF, application/xhtml+xml для XHTML, application/svg+xml для SVG и т.д. При этом обычные процессоры XML могут распознать, что документ находится в формате XML, а процессоры для обработки тех или иных специальных форматов способны определить, в каком именно формате он создан. В таблице 2 перечислены некоторые наиболее распространенные типы электронной корреспонденции.

Таблица 2. Типы электронной корреспонденции XML

Типы корреспонденции	Формат документа
image/svg+xml*	Масштабируемая векторная графика
application/atom+xml*	Синдикация атомарных данных
application/mathml+xml*	Математический язык разметки
application/beep+xml	Расширяемый протокол обмена блоков
application/cpl+xml	Язык обработки запросов
application/soap+xml	Сообщение SOAP
application/epp+xml	Расширяемый протокол инициализации
application/rdf+xml	XML-синтаксис описания ресурсов
application/xhtml+xml	Расширяемый язык разметки гипертекста
application/xop+xml	Бинарная оптимизированная организация пакетов XML
application/xslt+xml*	Таблица стилей расширяемого языка преобразования таблиц стилей
application/xmpp+xml	Расширяемый протокол обмена сообщениями и присутствия
application/voicexml+xml*	Голосовой расширяемый язык разметки

* Находится в процессе регистрации

Невозможно создавать новые типы электронной корреспонденции для каждого вновь появляющегося формата. Новые типы должны публиковаться в виде формальной спецификации (часто это так называемые "Запросы на комментарии" (Request for Comments) Проблемной группы проектирования Internet (Internet Engineering Task Force, сокр. IETF)) и регистрироваться в Агентстве по выделению имен и уникальных параметров протоколов Internet (Internet Assigned Numbers Authority - IANA). Но экспериментальные подтипы могут определяться и без регистрации. Они должны начинаться с символов х-. Например, тип корреспонденции для авторского языка разметки номенклатуры телевизоров, придуманного автором в качестве примера для его книги "Библия XML 1.1" (XML 1.1 Bible), может быть назван application/x-tvml+xml. Тип application указывает процессорам, что данный файл должен обрабатываться не как данные ASCII. Выражение +xml в конце названия подтипа информирует, что это файл XML, х- говорит о том, что это не зарегистрированный тип, а tvml несет информацию о виде данных.

Управление данными XML: подходы к определению документов XML

Эллиотт Расти Хэролд (Elliotte Rusty Harold)
Перевод: Intersoft Lab
Оригинал: Managing XML data: Identify XML documents

Название файла XML не обязательно должно иметь расширение .xml. Более того, документ XML даже не всегда может быть файлом. Он может представлять собой запись базы данных, часть файла, транзитный поток байтов в памяти, который даже не записывается на диск, или комбинацию нескольких различных файлов. Но многие документы XML все же хранятся на дисках или других носителях. В таком случае необходимо иметь возможность быстро их различать. В статье представлены наиболее распространенные расширения файлов и типы электронной корреспонденции (MIME media types), используемые в документах XML.

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

Если документы XML хранятся в виде файлов, то лучше использовать стандартные расширения. Это существенно облегчает поиск, распознавание и обработку файлов XML. На сегодня самым распространенным расширением является .xml, но для отдельных подмножеств XML используется и ряд других (табл. 1).

Таблица 1. Стандартные расширения файлов XML

Расширение	Значение
.xml	Общий документ XML
.ent	Элемент документа, фрагмент документа
.dtd	Определение типа документа
.rdf	XML-синтаксис описания ресурсов
.atom	Обеспечение синдикации атомарных данных
.owl	Язык онтологии web
.xhtml	Расширяемый язык разметки гипертекста
.xsd	Язык схем XML (W3C XML Schema Language)
.xsl	Преобразования расширяемого языка таблиц стилей (Extensible Stylesheet Language, сокр. XSL)
.fo	Форматирование объектов XSL
.rng	Синтаксис RELAX NG XML
.sch	Схема языка Schematron
.svg	Масштабируемая векторная графика
.rss	Простая синдикация (Really Simple Syndication), формат Rich Site Summary или RDF Site Summary
.plist	Формат списка свойств Apple

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

URI и адреса

Хотя на практике большинство URI являются адресами (URL - Uniform Resource Locators - унифицированные указатели информационных ресурсов), в пространствах имен XML они используются только как идентификаторы. К сожалению, пространства имен не могут идентифицироваться так же, как пакеты Java. Например: com.psol.vocabulary вместо более неопределенного http://psol.com/vocabulary.

Поскольку URI являются идентификаторами, адреса могут не работать, т.е. выдавать ошибку 404 - ресурс не найден - при попытке открыть их. Но они выполняют требуемые от них функции. И, вопреки широко распространенному заблуждению, URI пространств имен не указывают на схему XML Консорциума всемирной сети (World Wide Web Consortium - W3C).

Во-вторых, поскольку в этом контексте URI являются идентификаторами, приложение должно точно, до буквы, соответствовать их написанию. Было бы ошибкой использовать URI словаря XML для указания, например, на свой сервер. Например, URI для XSL выглядит следующим образом: http://www.w3.org/1999/XSL/Transform. Если пользователь работает в IBM, он не может превратить этот URI в, например, такой: http://www.ibm.com/1999/XSL/Transform. На самом деле изменения URI существующих словарей не допускаются вообще.

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

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

Встроенные функции XSL

В завершении приведем список внутренних функций, которые можно использовать в JavaScript –сценариях, предназначенных для анализатора msxsl:

Ancestor(elementType, elem)	Возвращает для текущего элемента ссылку на ближайший родительский элемент заданного типа. Если такого элемента нет или текущий элемент пустой, то возвращает null
ChildNumber(elem)	Возвращает индекс текущего элемента в списке других дочерних элементов данного типа.
AncestorChildNumber()	Возвращает номер ближайшего предка текущего элемента или null, если такового не существует
path(xsl)	Возвращает массив, содержащий "путь" к текущему элементу - в каждую ячейку этого массива помещается цифровое значение, указывающее на количество элементов одинакового типа, находящихся на текущем уровне вложенности. Первым значением этого массива будет представлен корневой элемент, последним - текущий. Размер массива определяет глубину вложенности текущего элемента.
HierarchicalNumberRecursive(elementType,elem)	Метод, похожий на метод path, но возвращает только дочерние элементы
FormatNumber(n,format)	Возвращает строку - символьное представление номера(т.е. "один", "два" и т.д.). Возможно определение следующих форматов: "1" - 0,1,2,.. "01" - 01,02,03,... "a" - a,b,c,..z, aa, ab,..zz "A" - A,..,Z,AA, .. ZZ
FormatNumberList(list,format,separator)	Возвращает строку, представляющую список, элементами которого являются символьные представления чисел

Назад | Содержание | Вперед

Вычисление выражений

Наиболее простым примером использования сценариев в XSL -документе является вычисление значений параметров описываемых элементов. Для этого надо просто поставить знак равенства в качестве первого символа параметра, что заставит XSL-процессор вычислить значение выражения(синтаксис этого выражения должен отвечать требованиям JavaScript). Например, после разбора этого правила:

, в выходном документе окажутся следующие инструкции:

Очень часто в правилах XSL необходимо использовать атрибуты описываемого в них элемента. Для этого мы должны воспользоваться методом getAttribute(), описанным в объектной модели XML (мы рассматриваем объектную модель XML-документов, предложенную Microsoft, список этих функций приведен в конце раздела). Т.к. каждому элементу XSL доступен указатель на соответствующий ему объект, сценарий может обращаться к внутренним функциям и свойствам этих элементов, при помощи которых и осуществляются необходимые действия.

В следующем фрагменте XML- документа определяется элемент <article>, в котором атрибут src используется для задания адреса файла, содержащего текст статьи.

<articles> <article src="http://server/pages/article.html">Bugs report</article> </articles>

Для того, чтобы использовать этот атрибут в выходном HTML-документе, необходимо определить следующее правило:

После обработки этого фрагмента в выходной документ будет помещен элемент:

<a href="http://server/pages/article.html">Bugs report</a>

Выполнение инструкций

Другим способом помещения в выходной HTML- документ информации, являющейся результатом выполнения каких-либо операций JavaScript – сценариев является использовнаие инструкции <eval>:

<rule> <element type="articles"> <target-element type="article"> </element> <tr><td><eval>childNumber(this)</eval></td><td> <children/> </td><tr> </rule>

Метод childNumber в данном случае возвращает текущий номер дочернего элемента.

XML-данные, хранимые в XML DB Repositoty

Но можно и приготовить торт, и съесть его, хотя бы до некоторой степени: Вы можете хранить ваш документ как некоторый Native XML Type (см. ниже) в репозитории XML DB (Oracle's XML DB repository), который целиком побайтно сохранит весь документ, а также “разнесет” его в SQL-таблицы. Такой подход предоставляет вам полную достоверность и в то же время позволяет вам выполнять все DML-операции с документом, которые доступны через XML Views. У вас по-прежнему сохраняется детализированное управление данными, и можно создавать множество представлений и документов на основе этих SQL-данных. После регистрации вашей XML-схемы вы запоминаете свои XML-данные в своей базе данных, просто вставляя файл XML-документа с применением SQL, PL/SQL, Java, FTP, HTTP или WebDAV. Выборка XML-данных из базы данных совершается выполнением SQL-запроса или чтением файла одним из стандартных протоколов Internet. Эта функциональность реализована благодаря поддержке встроенной перезаписи запросов (query re-write), которая снимает необходимость в триггерах типа instead-of-triggers.

Помимо легкости работы с XML в форме документа (в целом) или (отдельных) данных, вы получите расширение интерфейсов прикладного программирования объектной модели документа (Document Object Model (DOM) APIs) стандарта косорциума W3C при программном доступе. При разборе XML из файла вы можете построить в оперативной памяти представление в виде дерева всего файла для того чтобы манипулировать с ним. (Такой подход используют и другие XML-процессоры, такие как XSLT.) С возможностью “виртуальная DOM-модель” ("virtual DOM") собственного XMLType, описанной ниже, вы строите такое дерево по требованию: не только сохраняя ресурсы при применении интерфейсов DOM (DOM APIs) и XSLT, но в случае больших документов или наборов строк ваше приложение просто работает (а не падает).

Применение репозитория XML DB дает немало преимуществ, но это неверно для каждого приложения. Могут быть велики накладные расходы при поддержке отношения между полным документом и его “разложенными” (по таблицам) данными. Однако, основная проблема связана с эволюцией схемы. Так как документ (его структура) определяет процесс запоминания (отображение (mapping), какие данные в какие таблицы), то тогда, когда вы хотите изменить схему документа, этот процесс уже не абстракция, он “тонко” привязан к схеме базы данных, чья структура влияет на него. Это означает, что вы не можете выполнить большинство нетривиальных изменений схемы базы данных или документа, если не выполните экспорт всех данных и затем их импорт в базу данных.

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

XML Web

XML.COM - http://www.xml.com

XMLINFO.COM - http://www.xmlinfo.com/

SCHEMA.NET - http://www.schema.net/

Robin Coverґs SGML/XML Pages

- http://www.oasis-open.org/cover/

Microsoft's XML Web Site - http://www.microsoft.com/xml/

Microsoft's XSL Web Site - http://www.microsoft.com/xml/xsl

ArborText's XML resources page - http://www.arbortext.com/xmlresrc.html

Charles F. Goldfarb's SGML SOURCE HOME PAGE - http://www.sgmlsource.com/

DataChannel XML Resource Center - http://www.datachannel.com/xml_resources/

DEVELOPER.COM - XML Directory - http://www.developer.com/directories/pages/dir.xml.html

POET XML resource library - http://www.poet.com/xml/

XMLType CLOB

В некотором смысле, использование некоторого XMLType CLOB – это простейший способ хранения XML-файла. При этом документы в формате XML интерпретируются именно как документы. XML-файл сохраняется в структуре внешней памяти как полный текстовый документ (с пробелами (whitespace), комментариями и т.д. в нетронутом виде), при этом он запоминается просто как одна запись (строка символов) в базе данных. Следовательно, файлы любого размера и глубины (уровня вложенности, depth) могут быть сохранены, если они сформированы в формате XML.

Однако, хотя вы можете определить типы данных (datatypes) в документе для проверки по схеме (базы данных), этими данными нельзя манипулировать или выбирать их с применением SQL-запросов.

Из-за этого ограничения для поиска данных в документе нужно использовать механизм текстового поиска (text search engine), а не SQL-запросы, в которых можно воспользоваться функциональностью query rewrites, функциональными индексами и т.д. Эффективное изменение документа ограничено, так как оно требует выборки всего файла, совершения изменений и замены документа (в базе данных). Если, однако, основным назначением ваших XML-документов заключается инкапсуляция контента в некоторую структуру для преобразования (это прежде всего относится к публикации в Web, управлению контентом, архивированию документов и т.д.) и большинство изменений контента совершаются на уровне документа (в целом), тогда XMLType CLOB – это ваш оптимальный выбор для структур хранения XML-данных. В этих случаях, вряд ли вам нужен SQL-контекст для ваших данных и у вас будет гарантия побайтной сохранности (byte-by-byte fidelity). (См. во врезке примеры таких приложений.)

XSL

Using XSL and CSS together
W3C Note, 11 September 1998 - http://www.w3.org/TR/1998/NOTE-XSL-and-CSS-19980911

An Introduction to XSL by Henry S. Thompson HCRC Language Technology Group University of Edinburgh, Oct 27 1997 - http://www.ltg.ed.ac.uk/~ht/swindon.html

Understanding XSL
by Jay Greenspan28 October 1998 - http://www.hotwired.com/webmonkey/98/43/index2a.html

XSL Tutorials by Frank Boumphrey. - http://www.hypermedic.com/style/xsl/

"The MSXSL XSL Processor." Presentation made by Sean McGrath to SGML UK (SGML Users' Group) Tuesday, March 31, 1998. - http://www.sgml.org.uk/slides/xsl95/

Еще один способ определить, какие

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

если пользователь знает обо всех

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

Еще один способ определить, какие

если пользователь знает обо всех

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

Когда мы определяем модель содержимого текущего элемента, список дополнительных допустимых элементов правилами не ограничивается - он может свободно расширяться. Например, для приведенного выше правила, кроме обозначенных элементов <tel>,<url> и <email> вполне могут использоваться дополнительные элементы, неописанные правилами, например, <fax>:

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

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