SGML. SGML - структури. DTD, Детальна інформація

Визначення типу і структури документа: DTD

Формальний запис правил, таких, що були неформально описані вище, є першою стадією визначення структури SGML документа, а саме стадією розробки специфікації типу документа (Document Type Definition, DTD). Розробляючи DTD, дизайнер може задати тільки загальну ідею документа, не описуючі конкретностей і обмежень, або навпаки, явно задати їхній усі - у залежності від призначення типу документа; як уже відзначалося, така воля була однієї з головних цілей розробки SGML. Баланс між двома цими формами досягається при компромісі між легкістю проходження простим правилам і складністю обробки реальних текстів. Один зі складних випадків - обробка вже існуючих текстів. Розроблювач найчастіше має тільки загальне поняття про призначення оригінальних текстів і тільки базові ідеї про їхню структуру. У таких випадках найчастіше задаються самі загальні текстові елементи і найбільш вільні правила з взаємної композиції. З іншого боку, при розробки нових текстів, призначення яких точно відомо, розумно задати безліч обмежень, домагаючись тим гарантованої правильності і без проблемною подальшої обробки. Прикладом, де важливий саме такий підхід, може бути підготовка інформації для різних баз даних і знань. Навіть у випадку існуючого тексту може бути корисно задати обмежуючі правила які описують деяку гіпотезу про структуру документа - це принаймні допоможе перевірити адекватність цієї гіпотези. Важливо розуміти, що будь-яка специфікація типу документа - це інтерпретація тексту тільки з якоїсь однієї сторони. Не може бути єдиної DTD, придатної на усі випадки життя, що є "абсолютною істиною", крім, можливо, DTD, тавтологічно визначальної, що "текст є текст". Однак звичайно від такий DTD мало реальної користі. Таким чином, для різних цілей можуть знадобитися різні DTD, хоча, безумовно, невелика їхня кількість буде покривати найбільш важливі і часто використовувані області.

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

Проста DTD

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











Ці п'ять рядків приклад формальної декларації SGML-елементів. Декларація, також як і елемент, полягає в кутові дужки; перший символ після відкриваючої дужки повинний бути знак оклику, за яким одне з невеликого набору ключових слів SGML, що визначає, який об'єкт декларується. Усі п'ять декларацій вище того самого типу: вони починаються з ключового слова ELEMENT, що показує, що визначається елемент. Кожна декларація складається з трьох частин: ім'я тега (GI) чи група імен, два символи, які описують правила мінімізації, і модель змісту. Кожна їхньої цієї частин більш докладно описується далі. Компоненти декларації розділяються символом space, яким є послідовність пробілів, табуляцій і кінців рядків.

Generic Identifier

Перша частина декларації задає GI елемента, наприклад title, poem і т.д. Можливо одночасно визначити кілька елементів; ця можливість описується нижче.

Правила мінімізації

Друга частина декларації визначає те, що називається правилами мінімізації елемента. Правила мінімізації визначають, чи є необхідним явна вказівка старт- і енд-тегів при позначці елемента і записуються за допомогою пари символів, що відносяться до старт- і енд-тегу відповідно і розділених space символом. У будь-якому випадку, повинний бути заданий символ `-' (мінус), якщо тег обов'язковий, і `O' (omissible), якщо тег може бути опущений.

Таким чином, кожен елемент, крім повинний мати старт-тег. Тільки елемент повинний мати енд-тег.

Модель змісту

Третя частина декларації, укладена в дужки, називається моделлю вмісту (content model) елемента, оскільки вона описує елементи, що можуть міститися в даному. Вміст описується в термінах інших елементах і спеціальних зарезервованих словах. Існує кілька таких слів, з яких найбільше часто зустрічається #PCDATA, що є присутнім і в прикладі. Це абревіатура для послідовності символів, і вона означає, що елемент, описаний з її допомогою, може містити будь-як припустимі символи, тобто власне вміст тексту. Якщо розглядати специфікацію структури як дерево відносини елемент-вміст (мал. 2), що має одну кореневу вершину (у нашому випадку, ) і проміжні вершини (, , ...), то листами цього дерева майже у всіх випадках будуть #PCDATA.

Рис. 2 Дерево відносини елемент-вміст

У нашому випадку в такий спосіб задані