Главная » SQL, Базы данных » ОПРЕДЕЛЕНИЕ ДАННЫХ XML

0

Как и с обычными данными базы данных, с любым документом XML, как правило, связана определенная описательная информация. Такую информацию  можно задать с помощью либо определения типа документа (Document Type Definition — DTD), формируемого с использованием языка, который в данной книге именуется14 языком определения DTD [27.25], либо с помощью схемы XML, которая формируется на основе языка XML Schema (имеющего название, которое вносит определенную путаницу [27.28]). Оба этих языка рассматриваются в настоящем разделе.

Определения типа документа

Язык определения DTD описан в документе [27.25], который представляет  собой спецификацию XML (иными словами, определения типа документа  являются частью самого стандарта XML). Кроме всего прочего, в [27.25] приведены перечисленные ниже сведения.

■     Основные правила определения и использования языков разметки, основанных на XML (т.е. языков, производных от XML). Эти правила указывают, как различать разметку и символьные данные, как должным образом размещать попарно на чальные и конечные дескрипторы, как задавать комментарии и т.д.

■     Правила проектирования программ, предназначенных для обработки документов XML (которые принято называть синтаксическими анализаторами XML). Такие программы предназначены для предоставления информации другим программам.

Кроме того (как уже было сказано), в [27.25] приведены правила определения документов DTD.

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

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

<?xml version="1.О"?>

<!-Это представление в коде XML отношения деталей, приведенного

–>

<!-на рис. 3.8 (включены только кортежи, относящиеся к деталям Р1РЗ; –>

<!-значения COLOR и CITY теперь представлены в виде атрибутов

XML,  –>

<!-а не элементов XML).                                                                                                                                                                                                                                                  –>

<!DOCTYPE … ><!-См. приведенное ниже пояснение –>

<PartsRelation>

<NOTE>Revised version</NOTE>

<PartTuple CITY="London">

<PNUM>P1</PNUM>

<PNAME>Nut</PNAME>

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

<WEIGHT>12.0</WEIGHT>

<NOTE>Part color is Red by default</NOTE> </PartTuple>

<PartTuple COLOR="Green" CITY="Paris">     <PNUM>P2</PNUM>

<PNAME>Bolt</PNAME>

<WEIGHT>17.0</WEIGHT>

</PartTuple>

<PartTuple CITY="Oslo" COLOR="Blue"> <PNUM>P3</PNUM>

<PNAME>Screw</PNAME>

<WEIGHT>17 . 0</WEIGHT> </PartTuple>

</PartsRelation>

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

1. <!ELEMENT PartsRelation (NOTE?, PartTuple*)> 2. < ! ELEMENT NOTE (#PCDATA) >

3.     <!ELEMENT PartTuple (PNUM, PNAME, WEIGHT,NOTE?)>

4.     <!ATTLIST PartTuple

5.     CITY (London | Oslo | Paris) «REQUIRED

6.     COLOR (Red | Green | Blue) "Red">

7.     <!ELEMENT PNUM («PCDATA)>

8.     <!ELEMENT PNAME (#PCDATA)>

9.     <!ELEMENT WEIGHT («PCDATA)>

Пояснение

Строка 1. Каждый документ, который соответствует этому определению DTD, имеет один и только один корневой элемент, называемый PartsRelation. Этот корневой элемент содержит последовательность элементов PartTuple в количестве от нуля и больше, которым может предшествовать необязательный элемент

Примечание.  Необязательные  элементы   обозначаются  вопросительным    знаком,   а количество повторений "от  нуля и  больше" —  звездочкой15. Если  бы  в  этом документе вместо звездочки стоял знак плюса (т.е. если бы в него была включена строка PartTuple+, а не PartTuple*), то это означало бы "от единицы и  больше", а не "от нуля и больше". Если кратность повторения элемента не указана, это означает, что кратность повторения составляет "один и только один".

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

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

<!DOCTYPE  document   type name  [

15  Звездочка — это оператор Клина (Kleene), который уже встречался в главе 21.

Здесь имя типа документа document type name (в данном примере PartsRe-lation) должно   быть   таким   же,   как   и   имя   корневого    элемента.   Закрывающий разграничитель имеет следующую форму.

]>

■     При использовании внешнего определения эти разфаничительные строки в доку менте отсутствуют, а перед корневым элементом каждого документа, в котором используется определение DTD, находится ссылка на рассматриваемый документ DTD (поэтому в случае внешнего определения проще обеспечить совместное ис пользование одного и того же определения DTD в нескольких документах). Такая ссылка может выглядеть следующим образом.

<!DOCTYPE PartsRelation SYSTEM "file:///с:/parts.dtd">

Здесь  указано,  что  данное  определение  DTD  находится  в  файле   "parts.dtd". Поэтому даже в случае использования внешнего определения документ все еще имеет строку < ! DOCTYPE . . . >, в которой, кроме всего прочего, задано имя типа документа.

■     Строка 2. Каждый элемент NOTE содержит "синтаксически проанализированные символьные данные" (parsed character data — #PCDATA), а это, неформально гово ря, означает обычный текст без какой-либо разметки. Строки 7, 8 и 9 являются аналогичными.

■     Строка 3. Каждый элемент PartTuple содержит один и только один элемент PNUM, один элемент PNAME И ОДИН элемент WEIGHT (В указанном порядке), за ко торыми следует необязательный элемент NOTЕ.

■     Строки 4-6. Каждый начальный дескриптор PartTuple включает атрибут CITY и необязательный атрибут COLOR (если заданы оба атрибута, их последовательность не играет роли). Значением атрибута CITY должны быть строки London, Oslo или Paris. Значением атрибута COLOR должны быть строки Red, Green или Blue, и по умолчанию предполагается, что этот атрибут имеет значение Red, если он не задан.

Ниже приведен ряд дополнительных замечаний.

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

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

Формальная правильность

Любой конкретный текстовый объект X является формально правильным (well-formed)

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

■    Объект X не нарушает общих грамматических правил, которые определены в [27.25], и удовлетворяет всему набору из двенадцати правил, которые также определены в [27.25] (подробные сведения об этом выходят за рамки настоящей главы).

■     Каждый текстовый объект Y, на который явно или неявно указывает ссылка, при веденная в X, также должен быть формально правильным.

Примечание. Здесь выражение "явно или неявно" обозначает следующее: либо объект X содержит ссылку непосредственно на Y, либо объект X содержит ссылку  на некоторый другой текстовый объект Z, который явно или неявно содержит ссылку на Y.

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

<!-Предостережение! Этот текстовый объект не является формально

–>

<!-правильным (поэтому, по определению, вообще не является   –>

<!-документом XML).                                                                                                                                                                                                                                                     –>

<PartsRelation>

<PartTuple>

<PNUM>Pl</pnum> <!-Конечный дескриптор не соответствует начальному –>

<!-дескриптору                                                                                                                                                                     –>

<PNAME>Nut    <!-Пропущен конечный дескриптор                                                                                 –>

</PartTuple>

</PartTuple>    <!-Отсутствует начальный дескриптор                                         –>

</PartsRelation>

<PartsRelation>   <!-Больше одного корневого элемента                                        –>

Допустимость

Любой конкретный текстовый объект X является допустимым (valid) тогда и только тогда, когда он является формально правильным, а также соответствует некоторому заданному документу DTD. Ниже приведен пример документа  XML, который является формально правильным (по определению), но по причинам, указанным в комментариях, не может, тем не менее, считаться допустимым.

<!DOCTYPE PartsRelation SYSTEM "file:///с:/parts.dtd">

<!-Предостережение! Этот документ является формально правильным

(и                                                                                                                                                                                                                                                                                                                                                                            –>

<!-поэтому представляет собой документ XML). Но это не допустимый                                                                                                                                                                                                                                                                                                                                   –>

<!-документ PartsRelation, поскольку он не соответствует

определению                                                                                                                                                                                                                                                                                                                                  –>

<!-DTD для такого документа, которое приведено в файле

"parts.dtd". –>

<partsRelation>                                            <!-Не определенный элемент                                             –>

<PartTuple СITY="London">

<PNAME>Nut</PNAME>     <!-Элементы PNUM и PNAME …                                         –>

<PNUM>P1</PNUM>                                          <!-… приведены в неправильном порядке –> <WEIGHT>12 . 0</WEIGHT> </PartTuple>

<PartTuple>                                                                                <!-Пропущен атрибут CITY                                                                                 –>

< PNUM> P2 </PNUM>

<PNAME>Bolt</PNAME>

<remarks>Best quality</remarks>     <!-He определенный элемент –>

</PartTuple>                                             <!-Пропущен элемент WEIGHT –>

</partsRelation>

Атрибуты типа ID и IDREF

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

<!ATTLIST SupplierTuple SNUM ID #REQUIRED>

<!ATTLIST PartTuple PNUM ID #REQUIRED>

<!ATTLIST ShipmentTuple SNUM IDREF #REQUIRED>

<!ATTLIST ShipmentTuple PNUM IDREF #REQUIRED>

Здесь заслуживает особого внимания то, что теперь элементы PartTuple  имеют ат рибут PNUM, а не элемент PNUM. Если документ D является допустимым согласно этому определению DTD, то он отвечает приведенным ниже требованиям.

■     Каждый элемент SupplierTuple в документе D должен иметь уникальное значе ние SNUM, а каждый элемент PartTuple в D должен иметь уникальное значение PNUM.

■     Каждый элемент ShipmentTuple в документе D должен иметь значение SNUM, ко торое присутствует в качестве значения некоторого атрибута типа ID в каком-либо месте документа D, и значение PNUM, которое присутствует в качестве значения некоторого атрибута типа ID в каком-либо месте документа D.

Иными словами, атрибуты типа ID действуют в определенной степени  аналогично первичным ключам, а атрибуты типа IDREF — в определенной  степени аналогично внешним ключам. Но такие аналогии не являются достаточно полными по перечисленным ниже причинам.

16  В целом проблема применения ограничений целостности в контексте XML рассматривается в [27.8].

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

■    Не предусмотрен способ задания значения "ключа", который охватывает больше одного атрибута. (В данном примере следует отметить, что не было определено требование, согласно которому элементы ShipmentTuple должны иметь уникальное значение SNUM/PNUM.)

■    В этом примере значения SNUM В элементах SupplierTuple являются уникаль ными не просто по отношению ко всем другим элементам; они уникальны по от ношению ко всем атрибутам типа ID всего документа. Аналогичное

замечание от носится и к значениям PNUM В элементах PartTuple. (Поэтому, в частности, ни одно значение SNUM не равно какому-либо из значений PNUM.)

■    Кроме того, не гарантируется, что значения SNUM в элементах ShipmentTuple будут равны значению SNUM в некотором элементе SupplierTuple. Примени тельно к ним просто гарантируется, что они будут равны значению некоторого атрибута типа ID, находящегося в каком-либо месте документа.

■     Еще более важно то, что проверка ограничения ссылочной  целостности (в том виде, в каком она здесь предусмотрена) осуществляется только в пределах одного документа. Перекрестная проверка документов отсутствует.

Недостатки определений DTD

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

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

■  В   этих   определениях   не   используется   синтаксис   XML   (т.е.   сами   эти определения не являются документами XML), а это означает, что невозможно

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

XML. Например, рассмотрим следующее объявление элемента.

<!ELEMENT PNUM (#PCDATA)>

Это объявление немного напоминает начальный дескриптор XML, но не является таковым, поскольку "! ELEMENT" нельзя назвать допустимым именем типа элемента XML, a "PNUM" и " ( #PCDATA) " — допустимыми атрибутами XML. И на самом деле, если язык XML действительно является таким гибким и мощным, как часто приходится слышать, то он должен предоставлять возможность описать17 самого себя!

|7   Это заявление, безусловно, является чрезвычайно неформальным. Точнее, должна была  быть предусмотрена возможность определить такой язык XD, производный от XML, чтобы  документы, допустимые   в   соответствии   с   XD,   были   "определениями   типа   документа"    (безусловно,   не определениями  DTD  как  таковыми,  поскольку  уже  было  показано,  что  сами  определения  DTD являются  не  документами    XML,  а  "определениями  типа   документа"),  которые  предоставляют функциональные   возможности,                                         аналогичные   DTD,    и    в   идеальном   случае   также   многие дополнительные возможности. В действительности,  именно таким языком XD является XML Schema (см. следующий подраздел).

■     Эти определения, по существу, не обеспечивают поддержки типов данных (пос кольку в них любые данные представляют собой просто символьную строку).

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

<!ELEMENT PartTuple (PNUM, PNAME, COLOR, WEIGHT, CITY)>

В таком случае элементы PNUM, PNAME, WEIGHT, COLOR И CITY В любом конкретном элементе PartTuple должны присутствовать точно в указанном порядке, даже несмотря на то, что этот порядок не имеет значения в реляционных терминах.

Примечание. В принципе, можно сформулировать такое определение DTD,  кото рое позволит задавать эти пять элементов в произвольном порядке, но  только пу тем записи всех 120 разных возможных упорядочений (именно так!) в виде явных альтернатив с указанием того, что все эти 120 упорядочений равным образом при емлемы,

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

Но  несмотря  на  пе ре чис лен ные  выше  не дост ат ки ,  не л ь зя  от ри цат ь ,  что  в  осн о ве  опре делений  DT D  лежит  полностью   сложи в шийся  и  ва ж н ый  стандарт ,  а  сами  они  широко исп о льзу ютс я  на  практи ке .  Боле е  того ,  приме ня ем ые  в  реа л ьн ы х  приложен ия х  опре деле ния   DT D   об ыч но   являются   гора зд о   бол е е   сложными   и  разн осторонними ,   че м   можн о предп о ложит ь  на   основ а ни и  при в еденны х  здес ь  прос тых  приме р ов .  В  ч астност и ,  сам язы к   XM L  Sc he ma,  ко т ор ы й   расс мат р и в аетс я  в  сл е дующ ем   разделе ,   оп ре де ле н  с   помо щью документа DTD, имеющего объем  больше 400 строк (см. http: //www.w3 . org/ 2001/XMLSchema.dtd).

Язык XML Schema

Сам язык XML Schema [27.28] является производным от XML (но он не сформулирован как часть спецификации XML как таковой, в отличие от языка определения DTD). Поэтому схема XML, соответствующая любому конкретному документу D на языке XML, сама является документом XML, скажем, SD. Оформление явных, формально заданных связей между документами D и SD не предусмотрено, но в D может применяться специальный атрибут  schemaLocation,  который рассматривается как "подсказка", касающаяся местонахождения SD.

Как правило, в схеме XML предоставляется более обширный набор  ограничений, распространяющихся на документ (документы) XML, который в ней описан, чем можно было бы представить с помощью определений DTD. В качестве примера ниже приведен аналог на языке XML Schema определения DTD для документа PartsRelation, показанного в подразделе "Определения типа документа" выше в этом разделе (того определения, в котором данные COLOR и CITY представлены с помощью атрибутов, а не элементов XML).

<?xml version="1.0"?>

<!- Схема  XML  Schema  для  документов   PartsRelation  –>

<!DOCTYPE xsd:schema  SYSTEM "http://www.w3.org/2001/XMLSchema.dtd">

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd: element name="NOTE" type="xsd: string"/>

<xsd:element name="PartsRelation">

<xsd:complexType>

<xsd: sequence>

<xsd:element  ref="NOTE"  minOccurs="0"/>

<xsd: element  name="PartTuple"   type="PartTupleType"

minOccurs="0" maxOccurs="unbounded"/>

</xsd: sequence>

</xsd:complexType>

</xsd:element>

<xsd:complexType name="PartTupleType">

<xsd: sequence>

<xsd:element name="PNUM" type="PartNum"/> <xsd:element name="PNAME" type="xsd:string"/> <xsd:element name="WEIGHT"> <xsd:simpleType>

<xsd:restriction base="xsd:decimal">  <xsd: totalDigits value="5"/> <xsd:fractionDigits value="l"

fixed="true"/> <xsd:minlnclusive value="0.1"/>

</xsd:restriction> </xsd: simpleType> </xsd:element>

<xsd:element ref="NOTE" minOccurs="0"/> </xsd: sequence>

<xsd:attribute name="CITY" type="City"/>

<xsd:attribute name="COLOR" type="Color" default="Red"/>

</xsd:complexType>

<xsd: simpleType name="PartNum">

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

<xsd:pattern value=" P [0-9] {1,3} "/>

</xsd:restriction> </xsd: simpleType>

<xsd:simpleType name="Color">

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

<xsd:enumeration value="Red"/>

<xsd: enumeration value= "Green"/>

<xsd:enumeration value="Blue"/>

</xsd: restriction> </xsd:simpleType>

<xsd:simpleType name="City">     <xsd: restriction base="xsd: string"> <xsd:enumeration value="London"/> <xsd:enumeration value="Oslo"/>

<xsd: enumeration value=" Paris "/>

</xsd:restriction>

</xsd:simpleType>

</xsd:schema>

Вполне очевидно, что приведенная выше схема имеет гораздо больший объем и является более сложной, чем аналогичное ей определение DTD, даже несмотря на то, что по большей части в ней заданы такие же ограничения, как и в DTD. Основное различие между схемой и определением состоит в том, что схема налагает некоторые дополнительные ограничения типов на элементы и атрибуты. В языке XML Schema предусмотрено множество встроенных примитивных типов  —  boolean (логический), decimal (десятичный), string (строковый) и несколько  других, а также некоторые встроенные производные типы  —  integer  (целое   число),  positivelnteger  (положительное  целое  число), negativelnteger (отрицательное целое число и т.д.), которые определены в терминах примитивных типов. Этот язык позволяет также пользователям определять их собственные типы в терминах встроенных типов. Типы могут быть простыми или сложными; основное различие между ними состоит в том, что элементы сложного типа могут содержать вложенные в них другие элементы, а элементы, которые относятся к простому типу, такими свойствами не обладают. Ниже приведены  пояснения к этому описанию на основе схемы PartsRelation, которая налагает ограничения на документы PartsRelat ion.

1.          Корневой элемент (PartsRelation) определен как относящийся к анонимному сложному типу, значения которого определены в составе того же объявления как состоящие из необязательного элемента NOTE, за которым находится последова тельность элементов PartTuple в количестве от нуля и больше, а каждый из этих элементов относится к типу PartTupleType.

2.          Элементы, принадлежащие к типу PartTupleType, определены как состоящие из элементов PNUM, PNAME И WEIGHT В указанном порядке, наряду с атрибутами CITY и COLOR, последний из которых является необязательным (если он опущен, то по умолчанию применяется значение Red). В составе этих элементов и атрибу тов PNAME определен как относящийся к типу string, тогда как PNUM, CITY и COLOR, соответственно, определены как относящиеся к типам PartNum, city и Color, (см. пп. 4 и 5), a WEIGHT определен как относящийся к анонимному типу, объявление которого включено в данное объявление (см. п. 3).

3.          Тип элементов WEIGHT определен как сокращение типа decimal, которое имеет точность 5, коэффициент масштабирования 1 и минимальное значение 0. 1, иными словами, допустимыми значениями элементов типа WEIGHT ЯВЛЯЮТСЯ именно такие значения, которые входят в состав перечня чисел 0.1,   0 . 2 ,    . . . ,

9999.9.

4.          Тип PartNum (сокращение типа string) определен с помощью регулярного вы ражения Р [0 -9 ] {1,3}, которое интерпретируется как указание на то, что допус тимые значения типа PartNum состоят из прописной буквы Р, за которой следуют одна, две или три десятичные цифры.

Примечание. Такая конструкция, как регулярное выражение, заимствована из языка программирования Perl.

5.          Типы Color и city (которые также являются сокращениями типа string) опре делены с помощью перечислений.

Примечание. Несмотря на сказанное выше, важно учитывать, что "типы" языка XML Schema в действительности не являются типами в том смысле, который указан в главе 5. В частности, для них почти не определены соответствующие операции, что было бы обязательным для настоящих типов. "Определения типов" языка XML Schema фактически гораздо больше напоминают спецификации PICTURE, предусмотренные в таких языках, как COBOL и PL/I; это означает, что в действительности все, что они определяют, сводится к некоторым представлениям рассматриваемых "типов" в виде символьных строк. Отчасти по этим причинам автор счел себя вправе отказаться от использования обычных определяемых пользователем типов (например таких, как показано в главе 3) в предыдущем примере. Ниже перечислены некоторые преимущества использования языка XML Schema как средства описания документов XML по сравнению с языком определения DTD.

■     Схемы XML сами являются документами XML.

■    Язык XML Schema поддерживает гораздо более развитый механизм определения типов.

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

■    Язык XML Schema поддерживает элементы ключа key и ссылки на ключ keyref (также не показанные в данном примере), которые в большей степени напоминают такие конструкции, как реляционный ключ и внешний ключ. Указанные ключи могут состоять из комбинаций значений, взятых на различных уровнях вложенно сти данного конкретного элемента, поэтому обеспечивают, кроме всего прочего, поддержку такого ограничения, которое обычно именуется "уникальностью в пре делах родительского элемента" (см. главу 13 работы [1.5]).

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

■             Контроль некоторого конкретного документа XML с помощью схемы XML называется проверкой по схеме (schema validation), в отличие от простого неуточненного выражения "проверка" (validation), которое означает контроль документа с помо

щью определения DTD.

Поскольку схема сама является документом XML, она обычно содержит многочисленные элементы XML. Но заслуживает внимание то, что многие из этих элементов являются пустыми; как правило, пустые элементы фактически используются везде, где нужно указать элемент, имеющий атрибуты, но не имеющий информационного наполнения, как показано ниже.                                           <xsd:element name="NOTE"   type="xsd:string"/>

Такие же элементы можно найти в примере PartsRelation. Схемы также имеют свои собственные определения DTD, которые заданы с помощью следующей спе

<!DOCTYPE xsd:schema [ . . . ] >

И эту спецификацию можно найти в примере PartsRelation.

В заключение этого подраздела следует подчеркнуть тот факт, что здесь лишь бегло упомянуты возможности (и сложности) применения языка XML Schema. Дополнительная информация приведена в [27.14], а исчерпывающие сведения можно получить в спецификации языка XML Schema [27.28].

Дополнительные сведения о языках, производных от XML

Как было описано выше в этой главе, XML — это метаязык; это означает, что язык XML позволяет пользователям определять собственные специализированные языки и, в частности, предусматривать в них собственные определяемые пользователем дескрипторы. В связи с этим следует отметить, что каждое конкретное определение DTD и каждая схема XML представляют собой именно определение специализированного языка, т.е. такого "языка, производного OTXML", каким он был назван ранее. Иными словами, любое конкретное определение DTD и любая схема XML представляют собой именно определение синтаксических правил, которым должен подчиняться соответствующий им документ ХМ L.

Из сказанного выше следует, что XML — не просто метаязык, а скорее язык, который заслуживает названия "метаметаязыка". XML как таковой определяет (кроме всего про

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

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

тов, создаваемых в соответствии с этими правилами.

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии