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

Наброски и зарисовки растений, плодов, цветов: Освоить конструктивное построение структуры дерева через зарисовки отдельных деревьев, группы деревьев...

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

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

2020-04-01 127
Закрытая и открытая модели описания содержимого элемента 0.00 из 5.00 0 оценок
Заказать работу

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

<team> <title>Celtics</tel> <coach> … </coach> <player> … </ player > < assistant > … </ assistant > </ team >

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

<elementType id="team" content="CLOSED"> <element type="#title"> <element type="#player"> <element type="# assistant "> </elementType>

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

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

Для того, чтобы при описании класса ограничить список объектов, которые могут являться родительскими для данного элемента, необходимо использовать элемент схемы domain. Инструкция <domain> указывает, что текущий объект должен определяться строго внутри элемента, заданного этим тэгом. Например, в следующем фрагменте указывается, что элемент <player> может быть определен строго внутри тэга <team>:

<elementType id="player"> <element type="#name"> <domain type="#article"/> </elementType>

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

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

<elementType id="team"> <element type="#player"><min>11</min><max>25</max> </elementType>

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

Схема может использовать элементы и атрибуты из других схем. Для этого надо использовать атрибут href, в котором указывается название внешней схемы. Например:

<?XML version='1.0'?> <?xml:namespace name="urn:uuid:BDC6E3F0-6DA3-11d1- A2A3-00AA00C14882/" as="s"/?> <s:schema> <elementType id="player"> <any/> </elementType> <elementType id="title"> <string/> </elementType> <elementType id="team"> <element type="#title" occurs="REQUIRED"/> <element type="#player" occurs="ONEORMORE"/> <element href="http://mrcpk.org/" /> </elementType></s:schema> </elementType> </s:schema>

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

Компоненты, или макроопределении, используются в схемах точно также, как и в DTD. Для их определения предназначены тэги <intEntityDcl/> и <extEntityDcl/>;:

<intEntityDcl name=" gk "> goalkeeper </intEntityDcl> <extEntityDcl name="logo" notation="#gif" systemId="logo.gif"/>

Типы данных

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

<elementType id="counter"> <datatype dt="int"> </elementType>

В DTD мы должны были создать атрибут с конкретным названием, определяющим операцию назначения формата данных, и значением, определенным как fixed. Использование элемента <datatype> позволяет указывать это автоматически, но для обеспечения программной независимости необходимо сначала договориться об обозначениях типов данных(значения, которые должны передаваться параметру dt элемента datatype), для чего могут использоваться, например, универсальные идентификаторы ресурсов 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>…</comments> </house>...

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

 

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

Файл Clients.dtd

<!-- parameter entities -->

<!ENTITY % basic.content '#PCDATA'>

<!-- main elements -->

<!ELEMENT clients (client | visitor)*>

<!ELEMENT client (name, password, fullname, address, mail, age, e-mail?, registerIP?, lastlogin, money)>

<!ATTLIST client

id ID #REQUIRED

type (active | passive) #IMPLIED

>

<!ELEMENT visitor (registerIP?)>

<!ATTLIST visitor

id ID #REQUIRED

>

<!-- basic elements -->

<!ELEMENT name (%basic.content;)*>

<!ELEMENT password (%basic.content;)*>

<!ELEMENT fullname (%basic.content;)*>

<!ELEMENT address (%basic.content;)*>

<!ELEMENT mail (%basic.content;)*>

<!ELEMENT age (%basic.content;)*>

<!ELEMENT e-mail (%basic.content;)*>

<!ELEMENT registerIP (%basic.content;)*>

<!ELEMENT lastlogin (%basic.content;)*>

<!ELEMENT money (%basic.content;)*>

<!ATTLIST money

type (current | int) "int"

>

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

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE clients SYSTEM "Clients.dtd">

<clients>

<client id="client-20334-0001" type="active">

<name>John Silver</name>

<password>*********</password>

<fullname>John Fitzerald Silver</fullname>

<address>London, Piccadilli st. 467</address>

<mail>3458739 p.c. 3487 </mail>

<age>41</age>

<e-mail>[email protected]</e-mail>

<registerIP>172.36.01.12</registerIP>

<lastlogin>12.01.03</lastlogin>

<money>1290</money>

</client>

<client id="client-20334-0012" type="passive">

<name>Arthur Swift</name>

<password>*********</password>

<fullname>Arthur J. Swift</fullname>

<address>Dublin. Solar st. 463</address>

<mail>65863483 p.c 2342</mail>

<age>61</age>

<lastlogin>12.02.02</lastlogin>

<money type="current"> 1'000.0$</money>

</client>

<visitor id="client-20334-0023">

<registerIP>192.23.41.03</registerIP>

</visitor>

</clients>

 

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

<?xml version="1.0" encoding="UTF-8"?>

<!--W3C Schema generated by XML Spy v3.5 -->

<xsd:schema xmlns:xsd="http://www.w3.org/2000/10/XMLSchema">

 

<xsd:element name="clients">

<xsd:complexType>

<xsd:choice minOccurs="0" maxOccurs="unbounded">

<xsd:element name="client">

     <xsd:complexType>

          <xsd:sequence>

               <xsd:element name="name">

               <xsd:complexType mixed="true">

          <xsd:sequence minOccurs="0" maxOccurs="unbounded"/>

     </xsd:complexType>

</xsd:element>

<xsd:element name="password">

<xsd:complexType mixed="true">

<xsd:sequence minOccurs="0" maxOccurs="unbounded"/>

</xsd:complexType>

 </xsd:element>

<xsd:element name="fullname">

     <xsd:complexType mixed="true">

<xsd:sequence minOccurs="0" maxOccurs="unbounded"/>

     </xsd:complexType>

</xsd:element>

    

<xsd:element name="address">

<xsd:complexType mixed="true">

     <xsd:sequence minOccurs="0" maxOccurs="unbounded"/>

</xsd:complexType>

</xsd:element>

    

<xsd:element name="mail">

<xsd:complexType mixed="true">

<xsd:sequence minOccurs="0" maxOccurs="unbounded"/>

</xsd:complexType>

</xsd:element>

    

<xsd:element name="age">

<xsd:complexType mixed="true">

<xsd:sequence minOccurs="0" maxOccurs="unbounded"/>

</xsd:complexType>

</xsd:element>

    

<xsd:element name="e-mail" minOccurs="0">

<xsd:complexType mixed="true">

     <xsd:sequence minOccurs="0" maxOccurs="unbounded"/>

</xsd:complexType>

</xsd:element>

    

<xsd:element name="registerIP" type="registerIPType" minOccurs="0"/>

<xsd:element name="lastlogin">

 <xsd:complexType mixed="true">

<xsd:sequence minOccurs="0" maxOccurs="unbounded"/>

</xsd:complexType>

</xsd:element>

    

<xsd:element name="money">

<xsd:complexType mixed="true">

<xsd:sequence minOccurs="0" maxOccurs="unbounded"/>

<xsd:attribute name="type" use="default" value="int">

<xsd:simpleType>

     <xsd:restriction base="xsd:NMTOKEN">

     <xsd:enumeration value="current"/>

     <xsd:enumeration value="int"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

 

<xsd:attribute name="id" type="xsd:ID" use="required"/>

<xsd:attribute name="type">

<xsd:simpleType>

<xsd:restriction base="xsd:NMTOKEN">

<xsd:enumeration value="active"/>

<xsd:enumeration value="passive"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

</xsd:complexType>

</xsd:element>

 

<xsd:element name="visitor">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="registerIP" type="registerIPType" minOccurs="0"/>

</xsd:sequence>

<xsd:attribute name="id" type="xsd:ID" use="required"/>

</xsd:complexType>

</xsd:element>

</xsd:choice>

</xsd:complexType>

</xsd:element>

 

<xsd:complexType name="registerIPType" mixed="true">

<xsd:sequence minOccurs="0" maxOccurs="unbounded"/>

</xsd:complexType>

</xsd:schema>

 

Литература:

 

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

 

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

 

3. “Semantic Web: роли XML и RDF” С. Деккер – журнал ‘Открытые системы’ сентябрь 2001

 

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

 

 


Поделиться с друзьями:

История развития хранилищ для нефти: Первые склады нефти появились в XVII веке. Они представляли собой землянные ямы-амбара глубиной 4…5 м...

Особенности сооружения опор в сложных условиях: Сооружение ВЛ в районах с суровыми климатическими и тяжелыми геологическими условиями...

Автоматическое растормаживание колес: Тормозные устройства колес предназначены для уменьше­ния длины пробега и улучшения маневрирования ВС при...

Кормораздатчик мобильный электрифицированный: схема и процесс работы устройства...



© cyberpedia.su 2017-2024 - Не является автором материалов. Исключительное право сохранено за автором текста.
Если вы не хотите, чтобы данный материал был у нас на сайте, перейдите по ссылке: Нарушение авторских прав. Мы поможем в написании вашей работы!

0.053 с.