Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!
Текст из файла (страница 4)
Если мы включим приведенные правила внутрь XML-документа, программа-клиент сможет использовать их для проверки. Т.е. она теперь сможет определить, что правильным будет являться следующий фрагмент:
John Ree
Peter Loyd
Emil McGeer
team>
Все конструкции языка схем описываются правилами "XML DTD for XML-Data-Schema".
Область схемы данных
Создавая схемы данных, мы определяем в документе специальный элемент, ; внутри которого содержатся описания правил:
Если использовать отдельное пространство имен, то полный XML-документ, содержащий в себе схему данных, будет выглядеть следующим образом:
href="http://www.mrcpk.nstu.ru/schemas/" as="s"/?>
Описание элементов
Для определения класса элемента, к которому в дальнейшем будут применяться инструкции, описывающие его содержимое и структуру, предназначен специальный элемент схемы elementType. Название элемента задается атрибутом id . Все дальнейшие инструкции, которые относятся к описываемому классу, определяют его внутреннюю структуру и набор допустимых данных, содержатся внутри блока, заданного тэгами и . При определении класса элемента, можно также использовать комментарии к нему, которые заключаются в тэги <descript>
Атрибуты элемента
Для того, чтобы в описании элемента определить его атрибуты и описать свойства этих атрибутов нужно использовать элемент attribute:
…
В данном примере элементу layer> определяется атрибут number, значением которого может быть любая последовательность разрешенных символов:
<player number="0"/>
<player number="some text"/>
Подобно DTD, схемы данных позволяют устанавливать ограничения на значения и способ использования атрибутов. Для этого в дескрипторе необходимо использовать параметр atttype. Например, если мы хотим указать, что значение атрибута должно использоваться программой-анализатором как уникальный идентификатор, то нам необходимо создать следующее правило:
Если же требуется задать список возможных значений атрибута, то пример будет выглядеть следующим образом:
values="goalkeeper back halfback forward">
Модель содержимого элемента
Под моделью содержимого в схеме данных понимают описание всех допустимых объектов XML-документа, использование которых внутри данного элемента является корректным. Модель содержимого определяется инструкциями, расположенными внутри блока . Вложенные элементы описываются при помощи инструкции element, в которой параметром type указывается класс объекта - ссылка на его определение:
Если требуется указать режим использования вложенного элемента, то надо определить параметр occurs:
Возможные значения этого параметра таковы:
-
REQUIRED - элемент должен быть обязательно определен
-
OPTIONAL - использование элемента не является обязательным
-
ZEROORMORE - вложенный элемент может встречаться несколько раз или ни разу
-
ONEORMORE - элемент должен встречаться хотя бы один раз
Примеры правильных XML-документов, использующих приведенную выше схему:
<player>
John Ree
<nationality>Englishnationality>
Celtics
Portsmut
article>
или
John Ree
Celtics
<clubs>Portsmutclubs>
article>
Кроме элементов, содержимым XML-документа могут также является обычный текст и области CDATA. Для обозначения типов содержимого текущего элемента в схемах используются следующие инструкции:
-
- указывает на то, что содержимым элемента должны являться только элементы, без текста, незаключенного ни в один элемент:
Группировка элементов
Элемент group используется для того, чтобы задать некоторую последовательность вложенных объектов:
Группировка объектов позволяет определять сразу группу объектов различных типов, которые могут находится внутри данного объекта. В приведенном примере мы указали, что внутри объекта типа conteam могут быть включены элементы title, player, и assistant, причем атрибутом occurs мы указали, что элементы в группе являются необязательными. Корректным для таких схем будут являться следующие фрагменты документов:
Celtics
…
…
...
Celtics
...
Celtics
…
При помощи атрибута groupOrder можно также задавать режим использования группированных элементов При установленном значении OR возможно использование не всех элементов группы, а лишь некоторых из них. Если задано значение AND, то оба элемента должны быть включены в обязательном порядке. Например, для следующей группы правил:
будут считаться правильными только следующие варианты:
<team>
Celtics
…
…
или
Celtics
… player>
team>
Закрытая и открытая модели описания содержимого элемента
Когда мы определяем модель содержимого текущего элемента, список дополнительных допустимых элементов правилами не ограничивается - он может свободно расширяться. Например, для приведенного выше правила, кроме обозначенных элементов
,<player> и <assistant> вполне могут использоваться дополнительные элементы, неописанные правилами, например, <coach>: </p><p><b></b></p><p><b>Celtics</b></p><p><b> … </b></p><p><b> … </b><b></</b><b>player</b><b>></b></p><p><b><</b><b>assistant</b><b>> … </</b><b>assistant</b><b>></b></p><p><b></</b><b>team</b><b>></b></p><p> Однако в том случае, если мы хотим ограничить создаваемые нами правила от включения дополнительных элементов, мы должны использовать атрибут content и установить для него специальное значение CLOSED: </p><p><b></b></p><p><b></b></p><p><b></b></p><p><b><element type="#</b><b>assistant</b><b>"></b></p><p><b></b></p><p> Теперь приведенный фрагмент XML-документа будет считаться некорректным, т.к. параметром content запрещено использование внутри элемента <i>team</i><i> </i>других объектов, кроме указанных в правиле. </p><p> <b>Иерархия классов</b> </p><p> Для того, чтобы при описании класса ограничить список объектов, которые могут являться родительскими для данного элемента, необходимо использовать элемент схемы <b>domain</b>. Инструкция <b></b> указывает, что текущий объект должен определяться строго внутри элемента, заданного этим тэгом. Например, в следующем фрагменте указывается, что элемент <player> может быть определен строго внутри тэга <team>: </p><p> <b></b></p><p><b></b></p><p><b></b></p><p> <b></b></p><p> <b>Ограничения на значения </b> </p><p> Значения элементов могут быть ограничены при помощи тэгов <b> </b>и <b></b>;: </p><p> <b></b></p><p> <b>1125</b></p><p> <b></b></p><p> <b>Использование правил из внешних схем </b> </p><p> Схема может использовать элементы и атрибуты из других схем. Для этого надо использовать атрибут href, в котором указывается название внешней схемы. Например: </p><p><b></b></p><p><b><?xml:namespace name="urn:uuid:BDC6E3F0-6DA3-11d1-</b></p><p><b>A2A3-00AA00C14882/" as="s"/?></b></p><p><b><s> </s></b> </p><p><b></b></p><p> <b> </b> </p><p><b> </b> </p><p><b></b></p><p><b> </b> </p><p><b></b></p><p><b> </b> </p><p><b> </b> </p><p><b> </b> </p><p><b></b></p><p> <b></b></p><p><b></b></p><p><b></b></p><p> <b>Компоненты схем</b> </p><p> Компоненты, или макроопределении, используются в схемах точно также, как и в DTD. Для их определения предназначены тэги <b> </b>и <b></b>;: </p><p><b><intEntityDcl name="</b><b>gk</b><b>"></b></p><p><b>goalkeeper</b></p><p><b></b></p><p><b><extEntityDcl name="logo" notation="#gif"</b></p><p> <b>systemId="logo.gif"/></b></p><p> <b>Типы данных</b> </p><p> В схемах существует возможность задавать тот или иной тип данных, используя при определении элемента директиву <b> </b>с указанием конкретного типа: </p><p><b></b></p><p><b></b></p><p> <b></b></p><p> В DTD мы должны были создать атрибут с конкретным названием, определяющим операцию назначения формата данных, и значением, определенным как <i>fixed</i>. Использование элемента позволяет указывать это автоматически, но для обеспечения программной независимости необходимо сначала договориться об обозначениях типов данных(значения, которые должны передаваться параметру dt элемента datatype), для чего могут использоваться, например, универсальные идентификаторы ресурсов URI. В любом случае, как и прежде, все необходимые действия, связанные с конкретной интерпретацией данных, содержащихся в документе, осуществляются программой-клиентом и определяются логикой его работы. В разделе, посвященном DTD, мы уже рассматривали пример XML-документа, реализующего описанные нами возможности. Вот как выглядел бы этот пример при использовании схем данных: </p><p><b></b></p><p><b></b></p><p><b></b></p><p><b></b></p><p><b></b></p><p><b></b></p><p><b></b></p><p><b></b></p><p><b></b></p><p><b></b></p><p><b></b></p><p><b></b></p><p><b></b></p><p><b></b></p><p><b></b></p><p><b></b></p><p><b></b></p><p><b></b></p><p><b></b></p><p><b></b></p><p><b></b></p><p><b></b></p><p><b></b></p><p><b></b></p><p><b></b></p><p><b></b></p><p><b></b></p><p><b></b></p><p><b></b></p><p><b></b></p><p><b> </b> </p><p><b> </b> </p><p><b> </b> </p><p><b> </b> </p><p><b> </b> </p><p><b> </b> </p><p><b> </b> </p><p><b></b></p><p><b></b></p><p> <b>...</b></p><p><b></b></p><p><b>5</b></p><p><b>2</b></p><p><b>32.5</b></p><p><b>true</b></p><p><b>18346</b></p><p><b>34.28</b></p><p><b>…</b></p><p><b></b></p><p><b>...</b></p><p> Подводя итог всему сказанному, необходимо отметить, что процесс развития современных информационных систем настолько динамичен, что временной промежуток между появлением новой технологии и ее практическим использованием в реально действующих приложениях сегодня слишком мал. На смену устаревающему стандарту HTML в самое ближайшее время должен будет прийти новый, более гибкий и универсальный язык описания данных. И тот факт, что XML как язык еще не стандартизирован и некоторые его составляющие до сих пор находятся в стадии разработки, видимо, не является причиной невозможности его использования уже сегодня, для решения конкретных задач в реальных системах. </p><p> <br /> <br /> </p><p> <br /> <br /> </p><p> <b>Иллюстрационный</b><b> </b><b>пример</b></p><p> Файл Clients.dtd</p><p> <!-- parameter entities --></p><p> <!-- main elements --></p><p><!ATTLIST client</p><p> id ID #REQUIRED</p><p> type (active | passive) #IMPLIED</p><p>></p><p><!ATTLIST visitor</p><p> id ID #REQUIRED</p><p>></p><p> <!-- basic elements --></p><p> <!ATTLIST money</p><p> type (current | int) "int"</p><p> ></p><p> XML документ действительный для этого DTD</p><p> <clients></p><p> <client id="client-20334-0001" type="active"></p><p> <name>John Silver</name></p><p> <password>*********</password></p><p> <fullname>John Fitzerald Silver</fullname></p><p> <address>London, Piccadilli st. 467</address></p><p> <mail>3458739 p.c. 3487 </mail></p><p> <age>41</age></p><p> <e-mail>Silver@hotmail.com</e-mail></p><p> <registerIP>172.36.01.12</registerIP></p><p> <lastlogin>12.01.03</lastlogin></p><p> <money>1290</money></p><p> </client></p><p> <client id="client-20334-0012" type="passive"></p><p> <name>Arthur Swift</name></p><p> <password>*********</password></p><p> <fullname>Arthur J. Swift</fullname></p><p> <address>Dublin. Solar st. 463</address></p><p> <mail>65863483 p.c 2342</mail></p><p> <age>61</age></p><p> <lastlogin>12.02.02</lastlogin></p><p> <money type="current"> 1'000.0$</money></p><p> </client></p><p> <visitor id="client-20334-0023"></p><p> <registerIP>192.23.41.03</registerIP></p><p> </visitor></p><p> </clients></p><p> W3C схема эквивалентная предыдущему DTD</p><p> <!--W3C Schema generated by XML Spy v3.5 --></p><p> <xsd:schema xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"></p><p> <xsd:element name="clients"></p><p> <xsd:complexType></p><p> <xsd:choice minOccurs="0" maxOccurs="unbounded"></p><p> <xsd:element name="client"></p><p> <xsd:complexType></p><p> <xsd:sequence></p><p> <xsd:element name="name"></p><p> <xsd:complexType mixed="true"></p><p> <xsd:sequence minOccurs="0" maxOccurs="unbounded"/></p><p> </xsd:complexType></p><p> </xsd:element></p><p> <xsd:element name="password"></p><p> <xsd:complexType mixed="true"></p><p> <xsd:sequence minOccurs="0" maxOccurs="unbounded"/></p><p> </xsd:complexType></p><p> </xsd:element></p><p> <xsd:element name="fullname"></p><p> <xsd:complexType mixed="true"></p><p> <xsd:sequence minOccurs="0" maxOccurs="unbounded"/></p><p> </xsd:complexType></p><p> </xsd:element></p><p> <xsd:element name="address"></p><p> <xsd:complexType mixed="true"></p><p> <xsd:sequence minOccurs="0" maxOccurs="unbounded"/></p><p> </xsd:complexType></p><p> </xsd:element></p><p> <xsd:element name="mail"></p><p> <xsd:complexType mixed="true"></p><p> <xsd:sequence minOccurs="0" maxOccurs="unbounded"/></p><p> </xsd:complexType></p><p> </xsd:element></p><p> <xsd:element name="age"></p><p> <xsd:complexType mixed="true"></p><p> <xsd:sequence minOccurs="0" maxOccurs="unbounded"/></p><p> </xsd:complexType></p><p> </xsd:element></p><p> <xsd:element name="e-mail" minOccurs="0"></p><p> <xsd:complexType mixed="true"></p><p> <xsd:sequence minOccurs="0" maxOccurs="unbounded"/></p><p> </xsd:complexType></p><p> </xsd:element></p><p> <xsd:element name="registerIP" type="registerIPType" minOccurs="0"/></p><p> <xsd:element name="lastlogin"></p><p> <xsd:complexType mixed="true"></p><p> <xsd:sequence minOccurs="0" maxOccurs="unbounded"/></p><p> </xsd:complexType></p><p> </xsd:element></p><p> <xsd:element name="money"></p><p> <xsd:complexType mixed="true"></p><p> <xsd:sequence minOccurs="0" maxOccurs="unbounded"/></p><p> <xsd:attribute name="type" use="default" value="int"></p><p> <xsd:simpleType></p><p> <xsd:restriction base="xsd:NMTOKEN"></p><p> <xsd:enumeration value="current"/></p><p> <xsd:enumeration value="int"/></p><p> </xsd:restriction></p><p> </xsd:simpleType></p><p> </xsd:attribute></p><p> </xsd:complexType></p><p> </xsd:element></p><p> </xsd:sequence></p><p> <xsd:attribute name="id" type="xsd:ID" use="required"/></p><p> <xsd:attribute name="type"></p><p> <xsd:simpleType></p><p> <xsd:restriction base="xsd:NMTOKEN"></p><p> <xsd:enumeration value="active"/></p><p> <xsd:enumeration value="passive"/></p><p> </xsd:restriction></p><p> </xsd:simpleType></p><p> </xsd:attribute></p><p> </xsd:complexType></p><p> </xsd:element></p><p> <xsd:element name="visitor"></p><p> <xsd:complexType></p><p> <xsd:sequence></p><p> <xsd:element name="registerIP" type="registerIPType" minOccurs="0"/></p><p> </xsd:sequence></p><p> <xsd:attribute name="id" type="xsd:ID" use="required"/></p><p> </xsd:complexType></p><p> </xsd:element></p><p> </xsd:choice></p><p> </xsd:complexType></p><p> </xsd:element></p><p> <xsd:complexType name="registerIPType" mixed="true"></p><p> <xsd:sequence minOccurs="0" maxOccurs="unbounded"/></p><p> </xsd:complexType></p><p> </xsd:schema></p><p> <br /> <br /> </p><p> <br /> <br /> </p><p> <br /> <br /> </p><p> <br /> <br /> </p><p> <br /> <br /> </p><p> <b>Литература:</b></p><p> <br /> <br /> </p> <ul> <ol> <li> <p> “Изучаем XML” Э. Рей – Спб: Символ-Плюс, 2001.</p> </li></ol> </ul> <p> <br /> <br /> </p> <ul> <ol> <li> <p> “Мифы и реальности XML” Сергей Кузнецов - ИСП РАН, Центр информационных технологий.</p> </li></ol> </ul> <p> <br /> <br /> </p> <ul> <ol> <li> <p> “Semantic Web: роли XML и RDF” С. Деккер – журнал ‘Открытые системы’ сентябрь 2001</p> </li></ol> </ul> <p> <br /> <br /> </p> <ul> <ol> <li> <p> Материалы с CIT-forum’a</p> </li></ol> </ul> <p> <br /> <br /> </p><p> <br /> <br /> </p><p> <br /> <br /> </p><p> <br /> <br /> </p><p> <br /> <br /> </p><p> <br /> <br /> </p><p> <br /> <br /> </p><p> <br /> <br /> </p><p> Конец формы</p> </p></b></b></b></b></b></i></attribute></element></element>Характеристики
Учебное заведение
Неизвестно
Список файлов реферата
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
