SGML-структури. Поняття «тип документа», поняття «визначення типу документа» (визначення типу документа, DTD).

💸 Как сделать бизнес проще, а карман толще?

Тот, кто работает в сфере услуг, знает — без ведения записи клиентов никуда. Мало того, что нужно видеть свое раписание, но и напоминать клиентам о визитах тоже. Проблема в том, что средняя цена по рынку за такой сервис — 800 руб/мес или почти 15 000 руб за год. И это минимальный функционал. Нашли самый бюджетный и оптимальный вариант: сервис VisitTime.
⚡️ Для новых пользователей первый месяц бесплатно. А далее 290 руб/мес, это в 3 раза дешевле аналогов. За эту цену доступен весь функционал: напоминание о визитах, чаевые, предоплаты, общение с клиентами, переносы записей и так далее.
✅ Уйма гибких настроек, которые помогут вам зарабатывать больше и забыть про чувство «что-то мне нужно было сделать».
Сомневаетесь? нажмите на текст, запустите чат-бота и убедитесь во всем сами!

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

У стандарті SGML для текстових одиниць, що розглядаються як структурні компоненти, використовується термін елемент (element). Різним типам елементів даються різні назви, але SGML не пропонує ніяких способів висловити значення конкретного типу елементів, крім його відносини до інших типів елементів. Тобто, все, що можна сказати про елемент, який називається (наприклад) < blort>, - це те, що його екземпляри можуть зустрічатися (а можуть і не зустрічатися) всередині елементів типу < farble>, і що він може розкладатися (а може і не розкладатися) на елементи типу < blortette>. Слід підкреслити, що стандарт SGML абсолютно не турбує семантика текстових елементів: вона залежить від додатка (На даний момент йде робота по створенню (з використанням синтаксису SGML) визначення стандартного " мови семантики і специфікації стилів документів (document style and semantics specification language, DSSSL) ".) Справа творців SGML-сумісних наборів розміток (таких, як описаний в цьому Керівництво) - вибрати осмислені імена ідентифікаторів елементів і документувати правильне їх використання в розмітці текстів. Це - одна з цілей даного документа. Від необхідності вибору назв елементів, що кодують їх функцію, відбувається технічний термін для назви типу елемента: узагальнений ідентифікатор (generic identifier), або GI.

У розміченому тексті (примірнику документа, document instance) кожен елемент повинен бути явно розмічений або відзначений деяким чином. Стандарт надає кілька різних способів це зробити, найбільш часто використовуваний з них - вставити мітку (tag) на початку елемента (що відкриває мітка, start-tag) і ще одну - в кінці елементу (закриває мітка, end-tag). Пара відкриває і закриває міток використовується для виділення елементів в тексті, так само, як різні дужки або лапки використовуються у звичайній пунктуації. Наприклад, елемент цитування може бути відзначений в тексті так:

... репліка Розалінди < quote> Нічого дурнішого я ніколи не чула! < /quote> ясно показує...

Як показує даний приклад, що відкриває мітка має вигляд < назва>, де відкриває кутова дужка означає початок відкриває мітки, " назва" - узагальнений ідентифікатор відзначається елемента, і закриває кутова дужка означає кінець мітки. Закриває мітка має аналогічний вигляд, за винятком того, що за відкриває кутовий дужкою стоїть символ косою риси, так що відповідна закриває мітка буде < / назва>. (Насправді символи, використовувані в якості обмежувачів (кутові дужки, коса риса, знак оклику) можуть перевизначатися, але зручно використовувати символи, наведені в цьому описі.)

Елемент може бути порожнім (empty), тобто, не містити всередині взагалі нічого; елемент може містити просто текст. Частіше, однак, елементи одного типу будуть цілком міститися (embed) всередині елементів іншого типу.

Можливість використання правил, що встановлюють, які елементи можуть бути вкладені в інші, є дуже важливою властивістю SGML. Не переходячи до подальшого розбору цих правил, можна спробувати розглянути, як розмічений вищенаведеним чином текст може бути оброблений з різними цілями. Проста індексує програма може виділяти тільки значущі елементи тексту для генерації списку заголовків, або слів, використаних у тексті вірша; проста програма форматування може вставляти порожні рядки між строфами, можливо, починаючи з нового рядка перший рядок кожної строфи, або вставляючи номер строфи. Різні частини кожного вірша можуть набиратися різними способами. Більш складна аналітична програма може співвідносити використання знаків пунктуації зі строфовимі і метричними розділами. (Зауважимо, що цей простий приклад не бере до уваги проблему явною розмітки таких елементів, як пропозиції; слідства цього розглядаються нижче в розділі Альтернативні структури.) Дослідники, охочі бачити слідства змін розділів строф або рядків, вибраних редактором цього вірша, можуть це зробити просто змінюючи положення міток. І, звичайно, представлений вище текст може бути перенесений з одного комп'ютера на інший і оброблений будь-якою програмою (або людиною), що розуміє сенс внесених до нього міток, без жодних перетворень і трансляцій, необхідних зазвичай для переміщення файлів текстових процесорів.

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

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

Друга частина опису задає правила мінімізації для елемента. Ці правила визначають, чи зобов'язані бути присутніми відкриває і закриває мітки для кожної появи даного елемента. Вони мають вигляд пари символів, розділених пропуском, перший з яких відноситься до відкриваючої, а другий - до закриває мітці. В обох випадках повинні бути присутніми або мінус або буква O; мінус означає, що мітка повинна бути присутня, а буква O - що вона може бути опущена. Так, у нашому прикладі кожен елемент, окрім < line>, повинен мати відкриває мітку. Тільки елементи < poem> і < anthology> зобов'язані також мати і закриває мітку.

Третя частина кожного опису, укладена в круглі дужки, називається моделлю вмісту елемента, тому що вона вказує, що можуть містити екземпляри елемента. Вміст вказується або в термінах інших елементів, або за допомогою спеціальних зарезервованих слів. Є кілька таких зарезервованих слів, з яких саме часто використовується - #PCDATA. Це скорочення отparsed character data (розібрані символьні дані), і воно означає, що описуваний елемент може включати будь-які дозволені символьні дані. Якщо уявити собі SGML опис у вигляді структури на зразок генеалогічного дерева, з одним предком нагорі (в нашому випадку, це буде < anthology>), то майже завжди, якщо слідувати по гілках дерева вниз (наприклад, від < anthology> до < poem>, < stanza>, < line> або < title>), ми прийдемо до #PCDATA. У нашому прикладі так визначені < title> і < line>. Так як в їх моделі вмісту вказано тільки #PCDATA і не названо жодних включаються елементів, то вони не можуть містити інші елементи.

Вищенаведеий опис для < stanza> встановлює, що строфа складається з однієї чи більше рядків. Воно використовує позначення включення (occurence indicator) - знак плюс - для вказівки того, скільки разів може зустрічатися елемент, пойменований в моделі вмісту. У синтаксисі SGML є три позначення включення, зазвичай представлених знаком плюс, знаком питання і зірочкою. (Так само, як і обмежувачі, ці знаки мають формальні найменування і можуть бути перевизначені відповідним SGML описом.) Знак плюс означає, що відповідний елемент може зустрічатися один або більше разів; знак питання означає, що може бути не більше одного елемента; зірочка означає, що елемент може або бути відсутнім, або з'являтися один і більше разів. Так, якби модель вмісту для < stanza> була (LINE *), були б допустимі строфи без рядків, так само, як і з більш ніж одним рядком. Якби вона була (LINE?), То порожні строфи були б теж допустимі, але жодна строфа не могла б мати більш ніж один рядок. Опис < poem> в прикладі встановлює, що < poem> не може мати більше одного заголовка (але може не мати жодного) і що воно повинно мати як мінімум одну < stanza> (і може мати декілька).

Модель вмісту (TITLE?, STANZA +) містить більше одного компонента. Тому потрібно додатково вказати порядок, в якому ці елементи (< title> і < stanza>) можуть з'являтися. Це впорядкування визначається зв'язкою (group connector) - коми – використаної між її компонентами. Існують три можливі зв'язки, зазвичай подаються коми, вертикальної рисою і знаком " & ". (Так само, як обмежувачі і позначення включення, зв'язки мають в стандарті формальні імена і можуть бути перевизначені відповідним SGML описом.)

Кома означає, що обидва компонента, які вона з'єднує, повинні зустрічатися в порядку, зазначеному в моделі вмісту. Знак " & " вказує, що компоненти, які він з'єднує, повинні зустрічатися обидва, але в довільному порядку. Вертикальна риса означає, що може зустрічатися тільки один з компонентів, які вона з'єднує. Якби в нашому прикладі кому замінити на знак " & ", то заголовок міг би з'являтися або перед строфами вірші, або в його кінці (але не між строфами). Якщо її замінити на вертикальну риску, то вірш могло б полягати або з заголовка, або тільки з строф - але не з того й іншого.

До цих пір в нашому прикладі компоненти кожної моделі вмісту були або єдиним елементом, або #PCDATA. Цілком можна, однак, визначати моделі вмісту, в яких компонентами є списки елементів, об'єднані зв'язками. Такі списки, відомі як групи моделі (model groups), можуть також модифікуватися позначеннями включення і, в свою чергу, бути об'єднаними зв'язками. Щоб продемонструвати ці можливості, розширимо наш приклад так, щоб включати нестрофовие форми стіхов.Для демонстрації класифікуємо вірші на строфовие (stanzic), двовіршя (couplets), і білі (blank) або?? (stichic). Білий вірш складається просто з рядків (ігноруємо поки можливість віршованих абзаців) (Проникливий читач помітить той факт, що віршовані абзаци не обов'язково починаються на кордоні рядків, що серйозно ускладнює життя; див. Далі розділ Альтернативні структури.), Так що додаткових елементів не потрібно. Двовірш визначається як < line1>, за якою йде < line2>.

Елементи < line1> і < line2> (які розрізняються, наприклад, щоб зробити можливими вивчення схеми римування) мають в точності ту ж модель вмісту, що й існуючий елемент < line>. Вони, отже, можуть розділяти один і той же опис. У цій ситуації зручно вказати групу назв (name group) в якості першого компонента єдиного опису елемента, а не записувати послідовність описів, що відрізняються тільки використовуваними іменами. Група назв - це список GI, з'єднаний зв'язками і взятий у круглі дужки:

Опис елемента < poem> тепер можна змінити так, щоб включити всі три варіанти:

Тобто, вірш складається з необов'язкового заголовка, за яким слідує одна або кілька строф, або одне або кілька двовіршів, або одна чи кілька рядків. Відзначте різницю між цим визначенням і наступним:

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

Таким чином можна будувати досить складні моделі, відображаючи структурну складність різних типів текстів. У наступному прикладі ми розглянемо строфовий вірш, в якому з'являється рефрен (refrain). Він може складатися з повторень елементів-рядків або бути просто текстом, чи не розділеним на віршовані рядки. Рефрен може з'являтися тільки на початку вірша або як необов'язкове доповнення після кожної строфи. Це можна виразити моделлю вмісту кшталт такої:

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