ВИЗНАЧЕННЯ ДАНИХ XML

Як і з звичайними даними бази даних, з будь-яким документом XML, як правило, повязана певна описова інформація Таку інформацію можна задати з допомогою або визначення типу документа (Document Type Definition – DTD), формованого з використанням мови, який в даній книзі іменуется14 мовою визначення DTD [2725], або за допомогою схеми XML, яка формується на основі мови XML Schema (Що має назву, яка вносить певну плутанину [2728]) Обидва цих мови розглядаються в цьому розділі

Визначення типу документа

Мова визначення DTD описаний у документі [2725], який являє собою специфікацію XML (іншими словами, визначення типу документа є частиною самого стандарту XML) Крім усього іншого, в [2725] наведені перераховані нижче відомості

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

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

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

В якості ілюстрації функціональних можливостей DTD скористаємося переглянутої версією прикладу документа PartsRelation з розділу 273 Основні зміни полягають у наступному: для представлення квітів деталей і назв міст замість елементів використовуються атрибути XML крім того, в деяких місцях усередині

документа дозволено включати необовязковий елемент примітки NOTE Отже, типовий документ PartsRelation може виглядати так, як показано нижче

–&gt

XML,  –&gt

&ltPartsRelation&gt

&ltNOTE&gtRevised version&lt/NOTE&gt

&ltPartTuple CITY=&quotLondon&quot&gt

&ltPNUM&gtP1&lt/PNUM&gt

&ltPNAME&gtNut&lt/PNAME&gt

14 Термін мова визначення DTD повністю розшифровується як мова визначення визначень типу документа, тому на перший погляд може здатися, що в цьому терміні допущена деяка надмірність Але справа йде інакше, оскільки ці два визначення позначають різні поняття Додаткова інформація на цю тему приведена в підрозділі Додаткові відомості про мови, похідних від XML в самому кінці поточного розділу

&ltWEIGHT&gt120&lt/WEIGHT&gt

&ltNOTE&gtPart color is Red by default&lt/NOTE&gt &lt/PartTuple&gt

&ltPartTuple COLOR=&quotGreen&quot CITY=&quotParis&quot&gt     &ltPNUM&gtP2&lt/PNUM&gt

&ltPNAME&gtBolt&lt/PNAME&gt

&ltWEIGHT&gt170&lt/WEIGHT&gt

&lt/PartTuple&gt

&ltPartTuple CITY=&quotOslo&quot COLOR=&quotBlue&quot&gt &ltPNUM&gtP3&lt/PNUM&gt

&ltPNAME&gtScrew&lt/PNAME&gt

&ltWEIGHT&gt17 0&lt/WEIGHT&gt &lt/PartTuple&gt

&lt/PartsRelation&gt

Документи, що мають показану вище загальну форму, можуть мати визначення DTD, яке виглядає наступним чином (рядки в ньому пронумеровані для використання в подальших посиланнях)

1 &lt!ELEMENT PartsRelation (NOTE, PartTuple*)&gt 2 &lt ELEMENT NOTE (#PCDATA) &gt

3&nbsp&nbsp&nbsp&nbsp &lt!ELEMENT PartTuple (PNUM, PNAME, WEIGHT,NOTE)&gt

4&nbsp&nbsp&nbsp&nbsp &lt!ATTLIST PartTuple

5&nbsp&nbsp&nbsp&nbsp CITY (London | Oslo | Paris) «REQUIRED

6&nbsp&nbsp&nbsp&nbsp COLOR (Red | Green | Blue) &quotRed&quot&gt

7&nbsp&nbsp&nbsp&nbsp &lt!ELEMENT PNUM («PCDATA)&gt

8&nbsp&nbsp&nbsp&nbsp &lt!ELEMENT PNAME (#PCDATA)&gt

9&nbsp&nbsp&nbsp&nbsp &lt!ELEMENT WEIGHT («PCDATA)&gt

Пояснення

Рядок 1 Кожен документ, який відповідає цьому визначенню DTD, має один і тільки один кореневий елемент, званий PartsRelation Цей кореневий елемент містить послідовність елементів PartTuple в кількості від нуля і більше, яким може передувати необовязковий елемент

ПриміткаНеобовязкові елементи позначаються знаком питання, а кількість повторень від нуля і більше – Звездочкой15 Якби в цьому документі замість зірочки стояв знак плюса (Тобто якби в нього була включена рядок PartTuple +, а не PartTuple *), то це означало б від одиниці і більше, а не від нуля і більше. Якщо кратність повторення елемента не вказана, це означає, що кратність повторення складає один і тільки один.

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

■ При використанні внутрішнього визначення текст DTD передує кореневого елементу і повинен бути укладений у парні разграничители Хто відкриває розмежувач приймає наступну форму

&lt!DOCTYPE  document   type name  [

15 Зірочка – це оператор Клину (Kleene), який вже зустрічався у розділі 21

Тут імя типу документа document type name (У даному прикладі PartsRe-lation) повинно бути таким же, як і імя кореневого елементу Закриваючий розмежувач має наступну форму

]&gt

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

Тут вказано, що дане визначення DTD знаходиться у файлі partsdtd. Тому навіть у разі використання зовнішнього визначення документ все ще має рядок < ! 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 чи не порушує загальних граматичних правил, які визначені в [2725], і задовольняє всьому набору з дванадцяти правил, які також визначені в [2725] (докладні відомості про це виходять за рамки цієї глави)

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

Примітка Тут вираз явно або неявно позначає наступне: або обєкт X містить посилання безпосередньо на Y, або обєкт X містить посилання на деякий інший текстовий обєкт Z, який явно або неявно містить посилання на Y

З цих правил, крім усього іншого, випливає, що обєкт X повинен мати один і тільки один кореневий елемент, який може містити і зазвичай містить інші елементи початковий дескриптор кожного елемента повинен мати відповідний кінцевий дескриптор точно з таким же імям (причому при перевірці відповідності цих імен враховується регістр) елементи повинні бути вкладені правильно і тд У цьому сенсі всі наведені вище приклади документів XML були формально правильними (фактично, якщо текстовий обєкт не є формально правильним, то за визначенням його не можна вважати документом XML) Нижче для порівняння показаний текстовий обєкт, який не є формально правильним з причин, зазначених в коментарях

–&gt

&ltPartsRelation&gt

&ltPartTuple&gt

Pl

Nut

&lt/PartTuple&gt

&lt/PartsRelation&gt

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

Будь-який конкретний текстовий обєкт X є допустимим (Valid) тоді і тільки тоді, коли він є формально правильним, а також відповідає деякому заданому документу DTD Нижче наведено приклад документа XML, який є формально правильним (За визначенням), але з причин, зазначених в коментарях, не може, тим не менше, вважатися допустимим

визначенням ->

&quotpartsdtd&quot. –&gt

Nut

P1 12 0

&lt PNUM&gt P2 &lt/PNUM&gt

&ltPNAME&gtBolt&lt/PNAME&gt

Best quality

&lt/partsRelation&gt

Атрибути типу ID і IDREF

Цілком очевидно, що визначення DTD не забезпечують підтримки деяких типів обмежень целостності16 (не задають допустимі значення атрибутів і тд) Але здебільшого ці обмеження за своїм характером є досить слабкими (особливо стосовно до елементів, на відміну від атрибутів, безпосередньо містить фактичні дані, для яких, по суті, взагалі не можуть бути задані обмеження) Але визначення DTD забезпечують також підтримку деяких обмежень унікальності і посилальної цілісності завдяки наявності спеціальних типів атрибутів ID і IDREF Наприклад, припустимо, що потрібно задати визначення DTD для документа XML, відповідного не тільки відношенню з даними про деталі, але і всієї базі даних постачальників і деталей У такому випадку відповідне визначення DTD може включати оголошення, наведені нижче

&lt!ATTLIST SupplierTuple SNUM ID #REQUIRED&gt

&lt!ATTLIST PartTuple PNUM ID #REQUIRED&gt

&lt!ATTLIST ShipmentTuple SNUM IDREF #REQUIRED&gt

&lt!ATTLIST ShipmentTuple PNUM IDREF #REQUIRED&gt

Тут заслуговує на особливу увагу те, що тепер елементи PartTuple мають ат рібут PNUM, а не елемент PNUM Якщо документ D є допустимим згідно з цим визначенням DTD, то він відповідає наведеним нижче вимогам

■ Кожен елемент SupplierTuple в документі D повинен мати унікальне значення ня SNUM, а кожен елемент PartTuple в D повинен мати унікальне значення PNUM

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

Іншими словами, атрибути типу ID діють певною мірою аналогічно первинним ключам, а атрибути типу IDREF – певною мірою аналогічно зовнішнім ключам Але такі аналогії не є достатньо повними по перерахованих нижче причин

16 В цілому проблема застосування обмежень цілісності в контексті XML розглядається в [278]

■ Не передбачений спосіб завдання такого значення ключа, яке являло б собою щось інше, ніж проста символьний рядок

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

■ У цьому прикладі значення SNUM В елементах SupplierTuple є уникаль вими не просто по відношенню до всіх інших елементів вони унікальні по від носіння до всіх атрибутів типу ID всього документа Аналогічне

зауваження від носиться і до значень PNUM В елементах PartTuple (Тому, зокрема, жодне значення SNUM не дорівнює якомусь із значень PNUM)

■ Крім того, не гарантується, що значення SNUM в елементах ShipmentTuple дорівнюватимуть значенню SNUM в деякому елементі SupplierTuple Застосуй тельно до них просто гарантується, що вони будуть рівні значенням деякого атрибута типу ID, що знаходиться в будь-якому місці документа

■ Ще важливіше те, що перевірка обмеження посилальної цілісності (у тому вигляді, в якому вона тут передбачена) здійснюється тільки в межах одного документа Перехресна перевірка документів відсутня

Недоліки визначень DTD

Як було описано вище, передбачена у визначенні DTD підтримка обмежень цілісності є досить слабкою Насправді, відразу після того, як

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

■ У цих визначеннях не використовується синтаксис XML (тобто самі ці визначення не є документами XML), а це означає, що неможливо

забезпечити їх обробку за допомогою звичайного синтаксичного аналізатора

XML Наприклад, розглянемо наступне оголошення елементу

&lt!ELEMENT PNUM (#PCDATA)&gt

Це оголошення трохи нагадує початковий дескриптор XML, але не є таким, оскільки ! ELEMENT не можна назвати допустимим імям типу елемента XML, a PNUM і (# PCDATA) – Допустимими атрибутами XML І насправді, якщо мова XML дійсно є таким гнучким і потужним, як часто доводиться чути, то він повинен надавати можливість опісать17 самого себе

| 7 Ця заява, безумовно, є надзвичайно неформальним Точніше, мала бути передбачена можливість визначити таку мову XD, похідний від XML, щоб документи, допустимі відповідно з XD, були визначеннями типу документа (Безумовно, не визначеннями DTD як такими, оскільки вже було показано, що самі визначення DTD не є документами XML, а визначеннями типу документа), які надають функціональні можливості, аналогічні DTD, і в ідеальному випадку також багато додаткові можливості Насправді, саме такою мовою XD є XML Schema (див наступний підрозділ)

■ Ці визначення, по суті, не забезпечують підтримки типів даних (пос Кольку в них будь-які дані представляють собою просто символьну рядок)

■ Вони зазвичай вимагають, щоб елементи різних типів зявлялися в деякій за даної послідовності, навіть якщо ця послідовність не має якогось властивого їй сенсу Наприклад, припустимо, що документи PartsRelation мають визначення DTD, яке включає наступну специфікацію:

&lt!ELEMENT PartTuple (PNUM, PNAME, COLOR, WEIGHT, CITY)&gt

У такому випадку елементи PNUM, PNAME, WEIGHT, COLOR І CITY У будь-якому конкретному елементі PartTuple повинні бути присутніми точно в зазначеному порядку, навіть незважаючи на те, що цей порядок не має значення в реляційних термінах

Примітка В принципі, можна сформулювати таке визначення DTD, кото рої дозволить задавати ці пять елементів у довільному порядку, але тільки пу тим запису всіх 120 різних можливих упорядкувань (саме так) у вигляді явних альтернатив із зазначенням того, що всі ці 120 упорядкувань рівним чином при емлемой,

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

Але незважаючи на пе ре чис лені вищий не дост ат ки, що не л ь зя від ри цат ь, що в осн про ве виз поділів DT D лежить повністю склади в шийся і ва ж н ий стандарт, а самі вони широко ісп про ко ристь ЮТС я на практи ке Боле е того, примі ня ем ті в реа л ьн и х прикладений ия х визна справі ня DT D про зви чай але є гора зд про бол е е складними і різн Осторонь, че м можн про предп про покладає ь на основ а ні і при в єден х здес ь прос тих примі р ів У ч астност і, сам ська XM L Sc he ma, ко т ор и й расс мат р і в аетс я в сл е дующей ем розділі , Виз н за допомогою на щью документа DTD, що має обсяг більше 400 рядків (див http://wwww3 Org / 2001/XMLSchemadtd)

Мова XML Schema

Сама мова XML Schema [2728] є похідним від XML (але він не сформульований як частина специфікації XML як такої, на відміну від мови визначення DTD) Тому схема XML, відповідає будь-якій конкретній документом D на мові XML, сама є документом XML, скажімо, SD Оформлення явних, формально заданих звязків між документами D і SD не передбачено, але в D може застосовуватися спеціальний атрибут schemaLocation, який розглядається як підказка, стосується місцезнаходження SD

Як правило, у схемі XML надається більш великий набір обмежень, що поширюються на документ (документи) XML, який в ній описано, чим можна було б представити за допомогою визначень DTD Як приклад нижче наведено аналог на мові XML Schema визначення DTD для документа PartsRelation, показаного в підрозділі Визначення типу документа вище в цьому розділі (того визначення, в якому дані COLOR і CITY представлені за допомогою атрибутів, а не елементів XML)

&lt?xml version=&quot10&quot?&gt

&lt!DOCTYPE xsd:schema  SYSTEM &quothttp://wwww3org/2001/XMLSchemadtd&quot&gt

&ltxsd:schema xmlns:xsd=&quothttp://wwww3org/2001/XMLSchema&quot&gt &ltxsd: element name=&quotNOTE&quot type=&quotxsd: string&quot/&gt

&ltxsd:element name=&quotPartsRelation&quot&gt

&ltxsd:complexType&gt

&ltxsd: sequence&gt

&ltxsd:element  ref=&quotNOTE&quot  minOccurs=&quot0&quot/&gt

&ltxsd: element  name=&quotPartTuple&quot   type=&quotPartTupleType&quot

minOccurs=&quot0&quot maxOccurs=&quotunbounded&quot/&gt

&lt/xsd: sequence&gt

&lt/xsd:complexType&gt

&lt/xsd:element&gt

&ltxsd:complexType name=&quotPartTupleType&quot&gt

&ltxsd: sequence&gt

&ltxsd:element name=&quotPNUM&quot type=&quotPartNum&quot/&gt &ltxsd:element name=&quotPNAME&quot type=&quotxsd:string&quot/&gt &ltxsd:element name=&quotWEIGHT&quot&gt &ltxsd:simpleType&gt

&ltxsd:restriction base=&quotxsd:decimal&quot&gt  &ltxsd: totalDigits value=&quot5&quot/&gt &ltxsd:fractionDigits value=&quotl&quot

fixed=&quottrue&quot/&gt &ltxsd:minlnclusive value=&quot01&quot/&gt

&lt/xsd:restriction&gt &lt/xsd: simpleType&gt &lt/xsd:element&gt

&ltxsd:element ref=&quotNOTE&quot minOccurs=&quot0&quot/&gt &lt/xsd: sequence&gt

&ltxsd:attribute name=&quotCITY&quot type=&quotCity&quot/&gt

&ltxsd:attribute name=&quotCOLOR&quot type=&quotColor&quot default=&quotRed&quot/&gt

&lt/xsd:complexType&gt

&ltxsd: simpleType name=&quotPartNum&quot&gt

&ltxsd: restriction base= &quotxsd: string&quot&gt

&ltxsd:pattern value=&quot P [0-9] {1,3} &quot/&gt

&lt/xsd:restriction&gt &lt/xsd: simpleType&gt

&ltxsd:simpleType name=&quotColor&quot&gt

&ltxsd:restriction base=&quotxsd:string&quot&gt

&ltxsd:enumeration value=&quotRed&quot/&gt

&ltxsd: enumeration value= &quotGreen&quot/&gt

&ltxsd:enumeration value=&quotBlue&quot/&gt

&lt/xsd: restriction&gt &lt/xsd:simpleType&gt

&ltxsd:simpleType name=&quotCity&quot&gt     &ltxsd: restriction base=&quotxsd: string&quot&gt &ltxsd:enumeration value=&quotLondon&quot/&gt &ltxsd:enumeration value=&quotOslo&quot/&gt

&ltxsd: enumeration value=&quot Paris &quot/&gt

&lt/xsd:restriction&gt

&lt/xsd:simpleType&gt

&lt/xsd:schema&gt

Цілком очевидно, що наведена вище схема має набагато більший обсяг і є більш складною, ніж аналогічне їй визначення DTD, навіть незважаючи на те, що здебільшого в ній задані такі ж обмеження, як і в DTD Основна відмінність між схемою і визначенням полягає в тому, що схема накладає деякі додаткові обмеження типів на елементи і атрибути У мові XML Schema передбачено безліч вбудованих примітивних типів – boolean (логічний), decimal (десятковий), string (строковий) і кілька інших, а також деякі вбудовані похідні типи – integer (ціле число), positivelnteger (Позитивне ціле число), negativelnteger (відємне ціле число і тд), які визначені в термінах примітивних типів Ця мова дозволяє також користувачам визначати їх власні типи в термінах вбудованих типів Типи можуть бути простими або складними основна відмінність між ними полягає в тому, що елементи складного типу можуть містити вкладені в них інші елементи, а елементи, які відносяться до простого типу, такими властивостями не володіють Нижче наведені пояснення до цього опису на основі схеми PartsRelation, яка накладає обмеження на документи PartsRelat ion

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

2&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Елементи, належать до типу 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 є саме такі значення, які входять до складу переліку чисел 01, 0 2, ,

99999

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 роботи [15])

Безумовно, одним з негативних наслідків з описаного вище є те, що схеми XML стають набагато складнішими порівняно з простими визначеннями DTD На завершення даного опису мови XML Schema, необхідно навести декілька додаткових зауважень

■ Контроль деякого конкретного документа XML за допомогою схеми XML називається перевіркою за схемою (schema validation), на відміну від простого неуточненного виразу перевірка (Validation), яке означає контроль документа за допомогою на

щью визначення DTD

Оскільки схема сама є документом XML, вона зазвичай містить численні елементи XML Але заслуговує уваги те, що багато з цих елементів є порожніми як правило, порожні елементи фактично використовуються скрізь, де потрібно вказати елемент, що має атрибути, але не має інформаційного наповнення, як показано нижче

Такі ж елементи можна знайти в прикладі PartsRelation Схеми також мають свої власні визначення DTD, які задані за допомогою наступної спе

&lt!DOCTYPE xsd:schema [ ] &gt

І цю специфікацію можна знайти в прикладі PartsRelation

На закінчення цього підрозділу слід підкреслити той факт, що тут лише побіжно згадані можливості (і складності) застосування мови XML Schema Додаткова інформація наведена в [2714], а вичерпні відомості можна отримати в специфікації мови XML Schema [2728]

Додаткові відомості про мови, похідних від XML

Як було описано вище в цьому розділі, XML – це метамова це означає, що мова XML дозволяє користувачам визначати власні спеціалізовані мови і, зокрема, передбачати в них власні обумовлені користувачем дескриптори У звязку з цим слід зазначити, що кожне конкретне визначення DTD і кожна схема XML являють собою саме визначення спеціалізованої мови, тобто такого мови, похідного OTXML, яким він був названий раніше Іншими словами, будь-яке конкретне визначення DTD і будь-яка схема XML являють собою саме визначення синтаксичних правил, яким повинен підкорятися відповідний їм документ ХМ L

Зі сказаного вище випливає, що XML – не просто метамова, а скоріше мова, яка заслуговує назви метаметаязика. XML як такої визначає (крім усього про

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

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

тов, що створюються відповідно до цими правилами

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

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*