Опис схеми документа

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

Оголошення об'єктів-параметрів

Оголошення об'єкта-параметра визначає макрос певного типу, на який можна посилатися і який може бути розгорнутий десь у DTD. Ці макроси можуть з'являтися у самому документі, а бути лише у DTD. Якщо на об'єкт-параметр посилаються на ім'я їх DTD, то він розгортається в рядок, в якому вказано вміст цього об'єкта.

Об'єкт-параметр fontstyle містить у собі групу тегів TT | I | B | BIG | SMALL.

"#PCDATA | %fontstyle; | %phrase; | %special; | %formctrl;">

Об'єкт-параметр inline містить у собі текстові дані і ще чотири об'єкти-параметри fontstyle , phrase , special і formctrl .

Оголошення елементів

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

Різні ключові словата символи визначають вміст елемента:

• EMPTY - порожній вміст
• ANY - будь-який вміст
• , - Вказує порядок
• | - розподіл альтернатив
• () - угруповання
• * - будь-яка кількість елементів (нуль і більше)
• + - по Крайній міріодин елемент (один і більше)
• ? - необов'язкова наявність елемента (нуль чи один)
• Якщо немає *, + чи? - елемент має бути лише один

(DT | DD) +>

Елемент DL повинен містити один і більше елементів DT або DD у довільному порядку.

(%block;|SCRIPT) + -(FORM) >

Елемент FORM повинен містити один або більше елементів з об'єктом-параметром block або елементи SCRIPT в довільному порядку, однак виключена можливість містити ще один елемент FORM .

Визначення атрибутів

З кожним елементом документа DTD можна зіставити список атрибутів. Для цього використовується директива!ATTLIST , в якій вказуються ім'я елемента, з яким можна порівняти список атрибутів і параметри кожного атрибуту: його ім'я, тип і властивості за промовчанням.

Наприклад:

name CDATA #REQUIRED>

У цьому прикладі визначено атрибут name для елемента MAP. Він є обов'язковим.

Існують такі типи атрибутів:

• CDATA (Character set of data) – значенням атрибуту можуть бути будь-які символьні дані
• ID - значенням атрибута має бути унікальний ідентифікатор елемента
• IDREF - значення елемента є посилання на елемент за його ID
• IDREFS - теж що і IDREF, але з можливістю посилань не по одному ідентифікатору, а по кількох
• NMTOKEN - значенням атрибута може бути послідовність символів, у чомусь схожа на ім'я (звідси і назвою - name token). Це рядок, який містить будь-яку комбінацію тих символів, які можна використовувати для імен XML.
• NMTOKENS – значенням атрибуту є список значень
• ENTITY - значення використовується посилання на зовнішню сутність.
• ENTITIES - дозволяє встановити список зовнішніх сутностей, розділених пробілами.
• NOTATION - значенням атрибуту може бути одна з певних нотацій
• NOTATIONS – дозволяє задати список нотацій.
• Listings і NOTATION-listings
• ENUMERATION – задає список можливих альтернатив значень.

Існують такі властивості за промовчанням:

1. IMPLIED – значення атрибуту вказувати не обов'язково;
2. REQUIRED - значення атрибуту обов'язково має бути вказано;
3. FIXED - значення цього атрибута задано як константа DTD і в документі не може бути змінено;
4. деяке конкретне значення, яке використовується за умовчанням.

Зв'язок документа з певним DTD

Щоб зв'язати документ із певним DTD, необхідно на початку тексту документа вказати елемент Оголошення Типу документа.

Залежно від розташування DTD, Оголошення Типу Документу може бути двох видів:

• Внутрішнє підмножина DTD

Набір оголошень DTD міститься у самому тексті документа. Наприклад:

]> ]>

• Зовнішнє підмножина DTD

Набір оголошень DTD розміщується в окремому текстовому файліз розширенням.dtd У цьому випадку посилання на файл можна зробити через публічний ідентифікатор та (або) через системний ідентифікатор. Наприклад:

"http://www.w3.org/TR/html4/strict.dtd">

приклад

Приклад дуже простого XML DTD, що описує список людей:

(person*) > (name, birthdate?, gender?, socialecuritynumber?) > (#PCDATA) > (#PCDATA) > (#PCDATA) >

Починаючи з першого рядка:

1. Елемент Містить будь-яку кількість елементів Знак<*>означає, що можливо 0, 1 або більше елементів Всередині елемента .
2. Елемент Містить елементи , , і . Знакозначає, що елемент необов'язковий. Елемент не міститьщо означає, що елемент обов'язково повиненмістити елемент .
3. Елемент містить дані.
4. Елемент містить дані.
5. Елемент містить дані.
6. Елемент містить дані.

Приклад XML-документа, який використовує цей DTD:

> > > Fred Bloggs > > 27/11/2008> > Male > > 1234567890> > >

Див. також

Wikimedia Foundation. 2010 .

Дивитись що таке "DTD" в інших словниках:

DTD- , die in einer ASCII Datei (ASCII) abgelegte Eine DTD wird nach den Regeln der international anerkannten… … Universal-Lexikon

DTD- May stand for: Contents 1 Media 2 Music 3 Sports 4 Technologies 4.1 Computing … Wikipedia

DTD- steht für: Inhaltsverzeichnis 1 Medien 2 Music 3 Technologien 3.1 Computer 3.1.1 Spiele … Deutsch Wikipedia

Dtd- steht für: Darwin Digital Television, eine australische Fernsehstation Delta Tau Delta, eine US amerikanische Studentorganisation Document Type Definition, siehe Dokumenttypdefinition … Deutsch Wikipedia

DTD- (dē tē dēʹ) n. Набір правил для маркування документа в SGML. * * * … Universalium

DTD- (document type definition) specification written in the Standard Generalized Markup Language andрозміщення інформації про формат окремого документа (Computers) … English contemporary dictionary

20. Мови опису cхем XML

DTD схема. Недоліки DTD схем. XDR схеми. Елементи та атрибути XDR схем.

Ідея створення власних тегів, що мають спеціальне значення та допомагають описати зміст документа, сама по собі просто чудова. Але якщо кожен користувач може створювати власні описи, яким чином їх розпізнавати? З цією метою специфікації XML для опису подібних "самодіяльних" тегів використовуються схеми. Вони необхідні для того, щоб:

описати, що є розміткою;

описати точно, що означає розмітка.

Найбільш відомими мовами опису схем є такі:

DTD (Document Type Definition) - мова визначення типу документів, яка спочатку використовувалася як мова опису структури документа SGML.

XDR (XML Data Reduced) – діалект схеми XML, розроблений Microsoft, який підтримувався в Internet Explorer 4 та 5 версій.

XML Schema або XSD (мова визначення схем XML) – рекомендація консорціуму W3C з 2001 року.

Розглянемо докладніше перші з них. Третя мова опису схем розглядається у лабораторній роботі 11.

DTD схема

Схема DTD надає шаблон розмітки документа, в якому вказуються наявність, порядок прямування та розташування елементів та їх атрибутів у документі XML.

В рамках DTD модель вмісту XML документа можна описати так:

Кожен елемент документа може мати один із типів:

Атрибути, що знаходяться всередині тегів документа, описуються окремо за допомогою синтаксису:

ім'я_елемента ім'я_атрибута1 (тип) значення_за замовчуванням

…………………………………………………………………………………...

ім'я_елемента ім'я_атрибутаN (тип) значення_за замовчуванням >

При цьому атрибут DTD може мати один з трьох типів:

• Марковані атрибут

  Атрибут з перерахуванням

Крім типу атрибуту можна також ставити і його модальність:

Розглянемо як приклад опис атрибутів рядкового типу для елемента, що описує деяке повідомлення:

number CDATA #REQUIRED

date CDATA #REQUIRED

від CDATA #FIXED

status CDATA #IMPLIED>

Якщо цей елемент містить атрибути з перерахуванням, їх опис може виглядати, наприклад, таким чином:

number ID #REQUIRED

від CDATA #REQUIRED

alert (low | normal | urgent) "normal">

Марковані атрибути елемента можуть бути чотирьох типів:

І, нарешті, DTD можна використовувати такі індикатори входження послідовностей:

Як приклад наведемо DTD схему, що описує структуру електронної поштової скриньки:

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

[email protected]

[email protected]

Re:

[email protected]

[email protected]

Remind

[email protected]

Remind me про meeting.

Зверніть увагу на 2-у сходинку документа, в якій вказується зовнішнє посиланняфайл, що містить DTD схему.

В принципі DTD допускає два способи використання в XML документі.

Оголошення внутрішньої схеми:

Оголошення зовнішньої схеми:

На закінчення вкажемо на такі недоліки DTD схем:

Не є екземплярами XML. Потрібно вивчення зовсім іншої мови.

Не надають контролю над типами даних, крім найпростіших текстових даних.

Не є екземплярами XML, тому їх не можна легко розширити або перетворити на інші мови розмітки – HTML або DHTML.

Не підтримують простори імен XML.

XDR схема

XML-Data – повне ім'ямови опису схем, запропонованого Майкрософт, а XML-DataReduced - це "частина" повної рекомендації. Схема XDR - це екземпляр XML, тобто. відповідає всім синтаксичним правилам та стандартам XML.

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

Кореневим елементом у схемі XDR завжди є елемент Schema:

name="ім'я_схеми" xmlns="urn:schemas-microsoft-com:xml-data"

xmlns:dt="urn:schemas-microsoft-com:datatypes">

<-- Объявления других элементов -->

Елемент ElementType має синтаксис:

content="(empty | texOnly | eltOnly | mixed)">

dt:type "datatype"

model="(open | closed)"

order="(one | seq | many)"

Елемент ElementType може мати такі атрибути:

як дочірні елементи для ElementType можна використовувати такі:

Для оголошення атрибутів використовується синтаксис:

default="default-value"

dt:type="primitive-type"

dt:values="enumerated-values"

required="(yes|no)"

В свою чергу, елемент AttributeType може мати атрибути:

Синтаксис для опису елемента attribute виглядає так:

default="default-value"

type="attribute-type"

а його можливі значення можуть бути такими:

Анотація: У цьому розділі описуються загальні принципи написання Визначення типу документа. Також розглянуті основні недоліки та особливості DTD.

Навіщо потрібне DTD.

Створюючи XML документ, розробник сам вирішує: як назвати теги, в якому порядку вони будуть слідувати, які дані будуть записані в тому чи іншому елементі, чи будуть елементи атрибути чи ні і багато іншого. Без формального опису структури документа цим документом може скористатися лише його розробник. Якщо розроблений XML документ призначений для передачі в зовнішній світ, наприклад партнерам по бізнесу, і якщо до того ж планується отримувати у відповідь документи, написані в тому ж форматі без визначення типів документів (Document Type Definition, DTD) не обійтися. Це пов'язано з тим, що для того, щоб обидві сторони могли розуміти отриману інформацію елементи та атрибути в документах, повинні вживатися всіма сторонами однаково. Визначення типу документа вносять строгість і точність до правил написання правильно оформлених документів XML. Збережені на початку файлу XML або зовнішнім чином як файл *.DTD , визначення типів документів описують інформаційну структуру документа. У DTD перераховуються можливі імена елементів, визначаються наявні атрибути кожного типу елементів і описується вкладеність елементів.

XML використовується як засіб для опису граматики інших мов. І таким чином розробляючи деяку мову для написання XML документів у тій чи іншій галузі, нам доведеться розробити словник даної галузі діяльності. DTD за визначенням містять всю інформацію, яка може з'явитися в XML документі. Все, що входить до проекту, має бути включено до DTD . Таким чином, DTD описи по суті і є таким словником. Сучасний світ змінюється досить динамічно тому заздалегідь не відомо яка інформація може знадобитися в подальшому і для того, щоб не довелося часто змінювати структуру документів словник, що зазвичай розробляється, включає в себе все що може знадобитися для конкретних видів бізнесу або промисловості. Це дозволяє використовувати визначення DTD як аналіз і проектування. Додатки XML взаємодіють один з одним на основі словників, які вони розуміють, тому визначення DTD допомагає зрозуміти, що може описати програму .

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

Написання термінів DTD: загальні принципи.

Асоціація DTD із документом XML

Для зв'язування декларації DTD з екземпляром документа у версії XML 1.0 пропонується спеціальна декларація DOCTYPE. Вона має слідувати після декларації XML та передувати будь-яким елементам документа. Тим не менш, між деклараціями XML та DOCTYPE можуть бути коментарі та команди обробки.

Декларація DOCTYPE містить ключове слово DOCTYPE , за яким слідує ім'я кореневого елемента документа, а потім конструкція з деклараціями змісту. Перед роз'ясненням цього твердження розглянемо приклад розташування декларації DOCTYPE в екземплярі документа. Нижче наводяться перші три рядки документа XML:

.. …

Можна написати зовнішнє підмножина декларацій у окремому файлі DTD включити внутрішнє підмножина в тіло декларації DOCTYPE або зробити те й інше. В останньому випадку (змішування внутрішніх і зовнішніх DTD) у внутрішніх DTD можуть бути задані нові декларації або переписані ті, що містяться у зовнішніх (за визначенням специфікації XML аналізатори спочатку читають внутрішнє підмножина, і тому декларації, що містяться там, користуються пріоритетом).

Декларації XML можуть містити атрибут standalone, що приймає лише значення "yes" і "nо". Якщо значення атрибуту дорівнює yes, то зовнішні для екземпляра документа декларації не впливають на інформацію, що передається документом, що використовує його додатку. Значення no показує, що є зовнішні декларації зі значеннями, необхідні правильного описи змісту документа - наприклад конкретні значення за промовчанням. Насправді необов'язковий атрибут standalone використовується рідко. Наявність цього атрибуту зі значенням yes не гарантує відсутності зовнішніх залежностей будь-якого типу. Просто зовнішні залежності в цьому випадку не призведуть до помилки в документі, якщо не буде включено до обробки. Таким чином, в основному цей атрибут є знаком для аналізаторів та інших додатків, що показує, чи потрібно їм використовувати якийсь зовнішній зміст.

Блок внутрішньої декларації розмітки тега DOCTYPE складається з лівої квадратної дужки, списку декларацій та правої квадратної дужки:

Внутрішні DTD дуже корисні, вони завжди містяться у документі, що їх використовує, і тому їх отримання аналізатором не становить проблем. Однак, внутрішні DTD значно збільшують розмір документа. На практиці внутрішні DTD найчастіше застосовуються одночасно із зовнішніми для додавання нових декларацій. Якщо там оголошено якийсь об'єкт, продекларований також і у зовнішньому визначенні DTD, пріоритетом користується внутрішнє. Це дозволяє здійснювати тонке настроювання декларацій для потреб конкретних документів.

Зовнішні DTD у деяких відносинах гнучкіші. У даному випадкуДекларація DOCTYPE складається з звичайного ключового слова та імені кореневого елемента, за яким слідує ще одне ключове слово SYSTEM або PUBLIC, що позначає джерело зовнішнього визначення DTD, а за ним - локалізація цього визначення. Якщо ключове слово SYSTEM , DTD зобов'язане безпосередньо і явно знаходиться за вказаною URL-адресою.

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

Ключове слово PUBLIC призначене для добре відомих словників. Додаток, що аналізує документ із цього словника, повинен використовувати деяку стратегію пошуку відповідного DTD .

Стандарт XML 1.0 допускає у декларації PUBLIC наявність як публічного URI, так і системного ідентифікатора. Якщо додаток або аналізатор, що працює з документом, не можуть знайти DTD за ідентифікатором URI з ключовим словом PUBLIC , він повинен використовувати системний ідентифікатор.

Основні декларації розмітки

Допустимий у документі XML зміст визначається за допомогою чотирьох типів декларації розмітки в DTD. У наступній таблиці показані пов'язані з цими деклараціями ключові слова та їх значення:

Перші два типи пов'язані з інформацією, яку ми розраховуємо знайти в документі XML - елементами та атрибутами.

Останні два типи використовуються для підтримки. Особливо полегшують життя розробника словника XML сутності. Як правило, вони складаються із змісту, який настільки часто використовується у DTD або документі, що виправдовує створення спеціальної декларації. Застосування цієї декларації нагадує оператор include в мовах C/C++ , коли як заміна змісту використовується ім'я.

Нотації описують зміст, розроблений не мовою XML. Використовуються вони для того, щоб оголосити конкретний клас даних та пов'язати його із зовнішньою програмою. Ця зовнішня програма стає обробником оголошеного класу даних. Наприклад, зв'язавши з документом зображення у форматі JPEG, розробник бажає, щоб програма прийняла та візуалізувала двійкові дані у цьому форматі. Звісно, ​​у разі документ залежить від цього, який обробник є у системі, одержує документ. В інтересах портативності та переносимості деякі автори не наводять посилання на оброблювачі. У такому разі нотація перетворюється просто на механізм набору тексту.

У документах XML DTD визначає набір дійсних елементів, ідентифікує елементи, які можуть знаходитися в інших елементах, і визначає дійсні атрибути для кожного з них. Синтаксис DTD дуже своєрідний і від автора-розробника потрібні додаткові зусилля при створенні таких документів (складність DTD є однією з причин того, що використання SGML, що вимагає визначення DTD для будь-якого документа, не набуло такого поширення як, наприклад, HTML). Як уже зазначалося, у XML використовувати DTD не обов'язково - документи, створені без цих правил, будуть правильно оброблятися програмою-аналізатором, якщо вони відповідають основним вимогам синтаксису XML. Однак контроль за типами елементів та коректністю відносин між ними в цьому випадку повністю покладатиметься на автора документа. Доки граматика нашої нової мови не описана, її зможемо використовувати тільки ми, і для цього ми будемо змушені застосовувати спеціально розроблене програмне забезпечення, а не універсальні програми-аналізатори.

У DTD для XML використовуються такі типи правил: правила для елементів та їх атрибутів, опис категорій (макровизначень), опис форматів бінарних даних. Усі вони описують основні конструкції мови - елементи, атрибути, символьні константи, зовнішні файли бінарних даних.

Для того, щоб використовувати DTD в нашому документі, ми можемо або описати його в зовнішньому файлі і при описі DTD просто вказати посилання на цей файл або безпосередньо всередині самого документа виділити область, в якій визначити потрібні правила. У першому випадку в документі вказується ім'я файлу, що містить опис DTD:

...

Усередині документа DTD-декларації включаються таким чином:

... ... ]> ...

У тому випадку, якщо використовуються одночасно внутрішні та зовнішні описи, то програмою-аналізатором спочатку розглядатимуться внутрішні, тобто. їхній пріоритет вищий. Під час перевірки документа XML-процесор спочатку шукає DTD всередині документа. Якщо правила всередині документа не визначені та не заданий атрибут standalone ="yes", то програма завантажить вказаний зовнішній файл та правила, що знаходяться в ньому, будуть зчитані звідти. Якщо ж атрибут standaloneмає значення "yes", використання зовнішніх DTD описів буде заборонено.

Визначення елемента

Елемент DTD визначається за допомогою дескриптора! ELEMENT, в якому вказується назва елемента та структура його вмісту.

Наприклад, для елемента можна визначити таке правило:

Ключове слово ELEMENT вказує, що цією інструкцією описуватиметься елемент XML. Усередині цієї інструкції задається назва елемента (flower) та тип його вмісту.

У визначенні елемента ми вказуємо спочатку назву елемента (flower), та був його модель вмісту - визначаємо, які інші елементи чи типи даних можуть усередині нього. В даному випадку вміст елемента flower визначатиметься за допомогою спеціального маркера PCDATA (що означає parseable character data – будь-яка інформація, з якою може працювати програма-аналізатор). Існує ще дві інструкції, що визначають тип вмісту EMPTY,ANY. Перша вказує на те, що елемент повинен бути порожнім (наприклад, ), друга - те що, що вміст елемента спеціально не описується.

Послідовність дочірніх для поточного елемента об'єктів задається у вигляді списку розділених ком назв елементів. При цьому для того щоб вказати кількість повторень включень цих елементів можуть використовуватися символи +, *, ? :

У цьому прикладі вказується, що всередині елемента повинні бути визначені елементи title, author і table-of-contents, причому елемент title обов'язковим елементомі може зустрічатися лише один раз, елемент author може зустрічатися кілька разів, а елемент table-of-contents є опціональним, тобто. може бути відсутнім. У тому випадку, якщо існує кілька можливих варіантів вмісту елемента, їх слід розділяти за допомогою символу "|" :

Символ * у цьому прикладі вказує на те, що послідовність внутрішніх елементів, що визначається, може бути повторена кілька разів або ж зовсім не використовуватися.

Якщо визначенні елемента вказується " змішане " вміст, тобто. текстові дані або набір елементів, необхідно спочатку вказати PCDATA, а потім розділений символом "|" Список елементів.

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

]> ...

Визначення атрибутів

Списки атрибутів елемента визначаються ключовим словом! ATTLIST. Усередині нього задаються назви атрибутів, типи їх значень та додаткові параметри. Наприклад, для елемента