Skip to content Skip to navigation

A Gentle Introduction to SGML. Part 1. / Внимателно въведение в SGML. Част 1.

C. M. Sperberg-McQueen (Chicago University),

Lou Burnard (Oxford University)

Превод: Чавдар Витов

Редакция: Андрей Бояджиев

 

 

Предговор на редактора към българското издание

Идеята да се започне поредица от преводи на български на основни текстове, свързани с разбирането на маркиращите езици и технологии за Мрежата, възникна по време на дискусиите на международната конференция "Electronic Editions of Medieval and Modern Slavic Sources" в Поморие през септември 2002 г. Проф. Лу Бърнард бе така любезен да даде съгласието си да се преведат на български текстове, които той е писал в съавторство с проф. М. Сперберг-Мак Куин — двамата основни редактори на известната сред филолози и издателите, които се занимават с електронни публикации и маркиращи езици и технологии книга "Guidelines for the Electronic Text Encoding and Interchange". Тези преводи обхващат три уводни за проблематиката съчинения: "A Gentle Introduction to SGML", "A Gentle Introduction to XML" и "TEI Lite: An Introduction to Text Encoding for Interchange".

Началото на тази поредица се поставя със станалия христоматиен за всички, които се занимават с технологията на маркиращите езици текст на Лу Бърнард и Сперберг-Мак Куин A Gentle Introduction to SGML. Въпреки, че в наше време за SGML почти не се говори и повечето използват неговия опростен и по-добре ориентиран към Мрежата вариант, все пак SGML е стандартът, на който до голяма степен се дължи успеха на уеб технологиите, най-малко на едно от неговите приложения — езика HTML.

Текстът всъщност представлява втората глава от "Guidelines for the Electronic Text Encoding and Interchange" — ръководства, издавани от научния консорциум Text Encoding Initiative — (TEI). Много скоро обаче, тази втора глава е преведена на десетки езици и започва свой, самостоятелен, живот.

Факултетът по славянски филологии към Софийския университет е колективен член на TEI и курс по маркиращи езици се чете като част от дисциплините, преподавани в магистърската програма "Компютърна лингвистика. Интернет технологии в хуманитаристиката". Поради тази причина екипът на програмата счете за наложително поредицата от преводи да започне с този добре известен, христоматиен и нужен за студентите текст.

Българският превод е направен по електронния вариант на третото издание (P3) на "Guidelines ..." с любезното съгласие на проф. Лу Бърнард, за което сърдечно му благодарим.

Тук се публикува само първата част от "Внимателно въведение към SGML". Цялостният вариант е достъпен като първи том на поредицата Littera et Lingua. Series Traductiones. Vol. 1.

Редакцията на списанието и екипът на магистърската програма благодарят на преводача на "Внимателно въведение в SGML" — Чавдар Витов, който се зае с нелеката задача да намери адекватни български еквиваленти на редица популярни английски термини в областта.

Този превод нямаше да бъде извършен без любезната подкрепа на Фондация "Отворено Общество", в рамките на нейната програма "Обнова на висшето образование".

1. Увод в SGML

Кодиращата схема, представена в това ръководство, е формулирана като приложение към системата, известна като Стандартен обобщен маркиращ език (Standard Generalized Markup Language — SGML). SGML е международен стандарт за дефиниране на методи, независими от устройства и системи, за представяне на текст в електронна форма. Настоящата глава съдържа кратко ръководство за ползване на основните функции и е предназначена за тези читатели, които не са ги отчитали преди. За повече техническа информация на TEI практиката в ползването на SGML стандарта вижте глава 28; за по-подробно техническо описание на набора на SGML, използван в кодиращата схема на ТEI, вижте глава 39.

SGML е международен стандарт за описание на маркиран електронен текст. По-точно, SGML е метаезик, представляващ формално описание на език, в този случай — маркиращ език.

Погледнато в исторически план, думата „маркиращ" (обозначаващ — markup) се е използвала за описание на пояснителни бележки (анотации) или други уточняващи отбелязвания в даден текст, предназначени да указват на словослагателя или на набиращия текста как точно трябва да бъде набрана или отпечатана определена част от него. Примери за това са „вълнистото" подчертаване за отбелязване на получерен шрифт („bold"), специалните символи за отбелязване на пропуснати пасажи или такива, набрани с по-особен шрифт, и т.н. След като процесите на форматиране и печат станаха много по-автоматизирани, разглежданият термин разшири значението си и вече обхваща всички видове „кодирани маркирания" (markup codes), вмъквани в електронни текстове, за да се управлява форматирането, отпечатването и други видове обработка.

За да обобщим, следва да дефинираме значението на термина маркиране (или още кодиранеencoding) така: това е всеки един начин за представяне и/или интерпретиране на текст. Елементарно погледнато, всеки печатен текст има някаква употреба на условни (кодиращи) знаци — напр. пунктуационните знаци, употребата на главни и малки букви, разполагането на букви по страницата, дори празните пространства между думите може да се разглеждат като определен вид маркиране (обозначаване), чиято функция е да помогне на читателя да види къде свършва една дума и започва друга, или как да отличава основни структурни части, като например заглавия; или прости синтактични елементи, като подчинените изречения. Кодирането на текст за компютърна обработка по принцип, също както и преобразуването на ръкопис (scriptio continua), е процес, при който се разкрива и осмисля нещо, което е предполагаемо и изначално неразбираемо; процес на насочване на потребителя как точно да възприема и осмисля дадено съдържание на текст.

Под маркиращи езици разбираме група от общоприети правила (конвенции), които, сумарно взети, се използват при кодиране на текст. Маркиращият език трябва да определя какъв точно знак е разрешен, какъв се изисква, как да се отличава ясно от основния текст и какъв е смисълът на този знак. SGML предоставя средства за отговаряне на първите три изисквания; настоящото ръководство, както и подобните на него, се занимава с последното изискване.

Тази глава прави опит да даде едно неформално въведение — много по-малко формално от самия стандарт — в разбирането на тези съставни части на SGML, чието правилно осмисляне е твърде нужно за най-доброто ползване на ръководството.

2. С какво е по-особен SGML?

Има три характеристики на SGML, които го отличават от другите маркиращи езици: в него се набляга повече на описателните, отколкото на процедурните знаци; развита е концепцията за тип на документа (document type), езикът е независим от каквато и да било система за представяне на скрипта, в който е написан даден текст. Тези три аспекта накратко са разгледани по-долу, и по-задълбочено — в раздели 4. Структури на SGML и 5. Определяне на типа на документа в SGML — DTD.

2.1. Описателнo маркиране

Описателната маркираща система използва маркиращи кодове, които просто поставят имена за категоризиране на частите от документа. Маркиращите кодове като <para> или \end{list} просто идентифицират определена част от документа и посочват, че: „следващата част е абзац" или: „това е краят на последния започнат списък" и т. н. Противно на това процедурната система за маркиране определя каква обработка трябва да се извърши в дадена точка на документа: „тук се извиква процедура PARA с параметри 1, b и x" или „да се измести краят на лявото поле с два квадрата, дясната "с два квадрата надясно, да се пропусне един ред и да се отиде на новото ляво поле" и т. н. В SGML инструкциите, необходими, за да се обработи даден документ с определена цел (например за да се форматира), много ясно се различават от описателното маркиране, което се среща вътре в самия документ. Обикновено специалните знаци се събират извън документа, в отделни процедури или програми.

При описателното, а не процедурно маркиране, един и същи документ може лесно да се обработва с различни софтуерни програми, като всяка една може да прилага различни инструкции за обработка на такива части от документа, които приема за относително важни. Например една програма за анализиране на съдържание може напълно да пренебрегне поясненията и препратките в даден текст, свързани с него, докато програма за форматиране ги извлича и събира за отпечатване в края на всяка глава. Различен вид инструкции за обработка може да са свързани с една и съща част на съответния файл. Например една програма може да извлича от някакъв документ имена на хора и различни места, с цел създаване на индексен показалец или база данни, докато друга, обработваща същия текст, може да отбелязва с отличаващ се шрифт тези имена на хора и места.

 

2.2. Типове документи

На второ място SGML въвежда понятието тип на документа, от което се извежда определяне типа на документа (document type definition, DTD). Типът на документа формално се определя от неговите съставни части и тяхната структура. Например дефиницията за доклад може да бъде следната: той съдържа заглавие, също и автор, следвани от анотация и един, или няколко абзаца. Според това формално определение всичко, което няма заглавие, по правило не би могло да е доклад, както е и в случая, когато има поредност от абзаци, следвани от извлечение, независимо че са налице другите характеристики за този текст, които за одушевения читател го определят като доклад.

Ако документите са от известен тип, може да се използва програма със специално предназначение, наречена „парсър" (от „parse" — правя морфологичен, синтактичен разбор — бел. на преводача), която да изследва документа, претендиращ, че принадлежи към определен тип, и да провери дали всички части, изисквани за този тип документ, наистина са налице, подредени в точна последователност. По-важното е, че различни документи от един и същи тип може да се обработват по един и същи начин. Споменатите програми може да бъдат написани така, че да използват предимствата на съдържащата се в документа информация за структурата му, което би им позволило да извършват работата си по-интелигентно.

 

2.3. Независимост на данните

Главната цел за създаването на SGML бе да се осигури надежден пренос на кодирани документи без загуба на данни, независимо от дадената хардуерна платформа и/или софтуерна среда. Две от описаните по-горе свойства поставят това изискване на едно абстрактно ниво, третото свойство е насочено към ниво низ от байтове (знаци), от които е изграден документът. SGML предоставя общ механизъм за замяна на низове (string substitution), т.е. в процеса на обработка на документа, по един опростен, независим от машината начин, на междинен етап да се извършва заменяне на някаква поредност (низ) от знаци с друга поредност.

Едно очевидно приложение на този механизъм е да се осигури последователност и съгласуваност на номенклатурата; друго, по-важно е да се противопостави на печално известната неспоспособност на различните компютърни системи да разбират наборите от знакови обозначения (кодовите таблици) на другите системи, или способността на всяка една система да предостави всички графични символи, необходими на конкретното приложение, чрез описателно обозначаване на непреносимими знаци. Низовете, дефинирани от този механизъм за замяна на низове, се наричат обекти (entities) и се разглеждат по-долу в раздела 8. Обекти на SGML.

3. Структура на текста

Един текст не представлява просто недиференцирана (еднородна) последователност от думи, а още по-малко - само поредица от байтове. За различни цели текстът може да бъде разделян на множество различни части, с отличаващи се типове и големини. Прозаичен текст като настоящият може да се раздели на части, глави, абзаци и изречения. Един поетичен текст може да се раздели на части от поеми (стихотворни песни), строфи и редове. Веднъж напечатани, прозата и поезията може да се разделят на томове, сборници и страници.

Структурните единици от този вид най-често се използват за идентифициране специфичното разположение или справка (препратка) в самия текст (напр. „третото изречение на втори абзац в десета глава", „десета песен, стих 1234, страница 412" и т. н.), но те може също така да се използват за подразделяне текста на значими фрагменти с цел анализ („различава ли се средната дължина на изреченията в раздел 2 от тази на раздел 5?", „колко абзаца разделят всяка поява на думата природа?", „колко страници"?).

Други структурни елементи са чисто аналитични, тъй като характеризират част от даден текст. Текст от драматична постановка може да разглежда всяка реплика на отделен персонаж като част от един вид, а сценарните бележки или отбелязванията в текста, указващи движението по сцената - като части от друг вид. Такъв анализ е много по-малко полезен за откриване на части от текста („93-а реплика на Хораций във второ действие"), отколкото за улесняване на сравнението между думите, използвани от някое действащо лице, и тези, изговаряни от същото лице в различни сцени на пиесата.

По същия начин в един текст от проза може да се разграничат като части от различен тип пасажи пряка и непряка реч, такива, предадени в отличаващ се стил (повествователен, полемичен, коментарен, разсъдителен или под форма на спор, и т. н.), пасажи с различно авторство и т. н.

А за някои видове анализи (най-често - критика на текст) може да се окаже важно чисто физическото представяне на отделен печатен или ръкописен източник: парадоксалното е, че маркирането (обозначаването) може да се използва за описание свойствата на представително описание - такива като шрифт, прекъсвания на редове, използване на празни пространства (интервали) и т. н.

Тези текстови структури се пресичат една с друга комплексно, по непредвидим начин. Отчасти, когато работи с текстове, възпроизведени чрез технологията на печата, читателят трябва едновременно да осмисля както физическата организация на книгата, така и логическата структура на работата, съдържаща се в нея. Много велики творби (например Tristram Shandy на Лорънс Стърн) не може да бъдат оценени цялостно, без да се осъзнава ясно „играта", взаимовръзката между частите на повествованието (като главите и абзаците) и разделението на страниците. За различните видове изследвания това са взаимовръзките между различните нива на анализ, което е от изключително значение: размерът на взаимовръзките между синтактичната и повествователната структура, или например липсата на такива; или степента, в която фонетичните структури отразяват морфологията.

4. Структури на SGML

Този раздел описва простия и съгласуван механизъм на маркирането (обозначаването) или идентификацията на структурните части на текста, който механизъм се предоставя чрез SGML. Освен това той представя правилата, определящи как комбинациите от споменатите части може в напълно смислен вид да се срещнат във всякакъв текст.

4.1. Елементи

Техническият термин, използван в SGML стандарта за текстова част, разгледана като структурен компонент, е елемент. На различните видове елементи са дадени различни имена, но SGML не предлага начин как да се изразява значението на конкретен тип елемент, освен чрез неговата връзка с други типове елементи.

Така че всичко, което може да се каже за един елемент, наречен (например) <blort>, е, че такива като него може (или не може) да се срещнат вътре в елементи от типа <farble>, или че той може (или не може) да бъде разложен на елементи от типа <blortette>. Трябва да се отбележи, че SGML стандартът изобщо не се занимава със семантиката на текстовите елементи — тя изцяло зависи от конкретното приложение. 2

От създателите на SGML съвместимите набори от етикети (като описаните в това ръководство) пряко зависи да се подберат смислени имена за елементите, които идентифицират, и да документират тяхното правилно използване в маркирането на текстове. Това е едната от целите на този документ. От необходимостта да се изберат имена на елементите, които са показателни за функцията им, произтича и техническият термин за наименуване на типа елемент: обобщен идентификатор (generic identifier) или GI.

В един маркиран текст (на примерен документ) всеки елемент трябва по някакъв начин да бъде изрично маркиран или да има поставен етикет. Стандартът предоставя разнообразни различни начини да се направи това, като най-използваният е да се постави „начален етикет" в началото на елемента (start-tag) и друг, „краен етикет" — в неговия край (end-tag). Двойката етикети — начален и краен, се използва, за да се отделят срещанията на елементи в текста, точно както различните видове кръгли скоби и кавички се използват при обикновената пунктуация.

Например елемент на цитат може да бъде отбелязан (с етикети) в текста като:

Реплика на Розалинда <quote>Това е най-глупавото нещо, което съм чувала
някога!</quote> ясно показва ...

Както показва примерът, началният етикет приема формата <name> (<име>), където отварящите ъглови скоби отбелязват появата на началния етикет <name>, там е обобщеният идентификатор на елемента, който е бил ограничен, а затварящата ъглова скоба посочва края на етикета. Един краен етикет приема идентична форма с изключение на това, че отварящата крайна скоба е последвана от символа наклонена черта, така че съответстващият краен етикет ще бъде </name> (<име>).3

4.2. Модели на съдържанието — пример

Елементът може да бъде празен (empty), т.е. изобщо да не е изпълнен с никакво съдържание, пък може и да съдържа обикновен текст. Обаче много по-често елементите от един тип ще са вмъкнати (embedded — ще се съдържат изцяло) в елементи от друг тип.

За да илюстрираме това, ще разгледаме един много прост структурен модел. Да предположим, че в една антология искаме да идентифицираме само поемите, техните заглавия, строфи и редове, от които са съставени. Според терминологията на SGML, нашият тип на документа е антология (anthology) и съдържа серия поеми (poems). Във всяка поема е вмъкнат (embedded) един елемент, заглавие (title), срещат се няколко други заглавия, строфи; всяка строфа има вмъкнати в нея известен брой елементи - редове (lines). Изцяло маркиран, един текст, отговарящ на този модел, може да изглежда така: 4

<anthology>
<poem><title>The SICK ROSE</title>
<stanza>
<line>O Rose thou art sick.</line>
<line>The invisible worm,</line>
<line>That flies in the night</line>
<line>In the howling storm:</line>
</stanza>
<stanza>
<line>Has found out thy bed</line>
<line>Of crimson joy:</line>
<line>And his dark secret love</line>
<line>Does thy life destroy.</line>
</stanza>
</poem>
<!-- тук следват други поеми -->
</anthology>

Трябва да се изтъкне, че този пример не използва същите наименования, които са предложени за съответстващите елементи навсякъде в това ръководство — т.е. той не е валиден TEI документ. Примерът ще послужи само като въведение към основните понятия на SGML. Интервалите и прекъсванията на редовете („връщането на каретката") са добавени в този пример само за яснота и четимост; те нямат някакъв определен смисъл относно самото кодиране в SGML. Освен това редът

<!-- тук следват други поеми -->

е SGML коментар (comment) и не се третира като част от текста.

В този пример не се изяснява нищо за правилата, управляващи например дали едно заглавие може, или не може да се среща на други места, освен да предхожда първата строфа; дали може да има редове, които не са включени в дадена строфа - ето защо такова маркиране изглежда толкова многословно. В такива случаи началото и краят на всеки елемент трябва да бъдат ясно отбелязани, тъй като няма оформени правила за това кой елемент, къде може да се появи.

На практика обаче правилата обикновено са формулирани така, че да се намали нуждата от толкова голямо и подробно обозначаване с етикети. Например, като разгледаме нашия крайно опростен модел на поема, бихме могли да установим следните правила:

  • Една антология съдържа определен брой поеми и нищо друго.
  • Една поема винаги има един-единствен елемент - заглавие който предхожда първата строфа и не съдържа други елементи.
  • Ако оставим настрана заглавието, поемата се състои само от строфи.
  • Строфите се състоят само от редове и всеки ред се съдържа в строфа.
  • Нищо не може да следва строфа, освен друга строфа или краят на поемата.
  • Нищо не може да следва ред, освен друг ред или началото на нова строфа.

От тези правила може да се заключи, че не се налага изрично да маркираме краищата на строфите или редовете. От правило 2 следва, че няма нужда да маркираме края на заглавие - той се подразбира от началото на първата строфа. По същия начин, от правило 3 и 1 следва, че ние трябва да маркираме края на поемата, тъй като поемите не могат да се срещат вътре в други поеми, но трябва да са разположение в антологии, така че краят на една поема по подразбиране е следван от началото на следващата или от края на антологията. Прилагайки тези опростявания, ние можем да маркираме (обозначим) същата поема така:

<anthology>
<poem><title>The SICK ROSE
<stanza>
<line>O Rose thou art sick.
<line>The invisible worm,
<line>That flies in the night
<line>In the howling storm:
<stanza>
<line>Has found out thy bed
<line>Of crimson joy:
<line>And his dark secret love
<line>Does thy life destroy.
<poem>
<!-- тук следват други поеми -->
</anthology>5

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

Преди да разгледате тези правила по-нататък, може би ще поискате да разберете как така маркираният по-горе текст може да бъде обработен от компютър за най-различни цели.

Една елементарна индексираща програма може да извлече само значимите текстови елементи, за да състави списък от заглавия или думи, използвани в поетичния текст; една несложна форматираща програма може да вмъкне празни редове между строфите, би могла да направи отстъп за първия ред или да вмъкне номер на всяка строфа. Различните части на всяка поема може да бъдат набирани по различни начини. Една по-амбициозно направена аналитична програма би могла да свърже употребата на пунктуационни знаци с тези на строфите и мерената реч. Учените, които желаят да видят последствията от измененията на разделите от строфи или редове, избрани от редактора на тази поема, могат да го направят просто като променят позицията на етикетите. И, разбира се, представеният по-горе текст може да бъде прехвърлен от един компютър на друг и обработен от всяка програма (или човек), която е в състояние да осмисли етикетите, вмъкнати в текста, без да се налагат каквито и да било преобразувания и прехвърляния на файлове, изисквани обикновено от текстообработващите програми.

5. Определяне типа на документа в SGML - DTD

Правила, подобни на описаните по-горе, са първото стъпало при създаването на формална спецификация на структурата в един SGML документ, или определяне типа на документа (document type definition), обикновено съкращавано като DTD. При създаване на DTD оформителят на документа може според желанието си да го направи с произволно свободна или стегната структура. Трябва да се поддържа балансът между удобството да се следват прости правила и сложността при работата с истински текстове. Това с особена сила важи в случаите, когато правилата са били определени спрямо текстове, които вече съществуват — оформителят може да има само мъглява представа за първоначалната цел, с която е създаден някакъв стар текст, или за смисъла му, и оттам нататък да прецени, че е много трудно тепърва да задава постоянни правила за неговата структура. От друга страна, когато един нов текст е бил създаден с точна спецификация, например за вкарване в текстова база данни от някакъв вид, колкото по-прецизно са установени правилата, толкова по-добре може да бъдат спазвани. Даже в случай, при който един съществуващ текст вече е бил маркиран, определно ще има полза да се дефинира ограничен брой правила относно даден поглед върху текста или работна хипотеза за този текст — дори и само за проверка полезността на този поглед или тази хипотеза. Важно е да се помни, че всяко определение за типа на документа представлява интерпретация на текста. Не съществува единствена DTD, която обхваща всяка разновидност и е абсолютно вярна за даден текст, макар че за конкретни типове анализ може да се окаже доста удобно предпочитането на някои DTD пред други.

В наше време SGML е много по-широко използван в среда, където главно изискване е структурната уеднаквеност на документите. Например при създаването на техническа документация е изключително важно определени раздели и подраздели да бъдат разположени много прецизно, така че съответно точни да бъдат кръстосаните препратки, и т. н.

В такива ситуации документите се разглеждат като необработен, суров материал, към който се прилага предварително дефиниран набор от правила. Обаче, както обсъдихме по-горе, ряботата с опростени правила може също да опрости изключително много задачата да се поставят акуратно етикети на елементите в по-малко ограничени текстове. Като прави открити такива правила, един учен намалява тежката работа по маркирането и проверката на електронен текст, като заедно с това разкрива интерпертацията на структурата и и важните особености на текста, който бива кодиран.

5.1. Пример за DTD

DTD е представен в SGML като набор декларативни твърдения използващи опростен синтаксис, дефиниран в стандарт. За нашия елементарен модел на поема биха били подходящи следните декларации:

<!ELEMENT anthology - -  (poem+)>
<!ELEMENT poem - - (title?, stanza+)>
<!ELEMENT title - O (#PCDATA) >
<!ELEMENT stanza - O (line+) >
<!ELEMENT line O O (#PCDATA) >

Тези пет реда са примери за формални елементни декларации на SGML. Една декларация, както и елемент, са оградени от ъглови скоби; първият знак, следващ отварящата скоба, трябва да бъде удивителен знак, незабавно последван от една от ключовите думи, дефинирани в малкия набор на SGML, указващи от какъв вид е обектът, който се декларира.

Всичките пет декларации по-горе са от един и същи тип — всяка започва с ключовата дума ELEMENT, показвайки, че това декларира елемент в техническия смисъл, изяснен по-рано. Всяка декларация се състои от три части: име или група от имена, два знака, определящи правилата за минимизиране (minimization rules) и модела на съдържание (content mode). Всяка от тези части е разгледана по-нататък. Компонентите на декларацията се разделят от празно пространство, което е един или няколко интервала (шпации), табулации или нови редове.

Първата част на всяка декларация горе дава обобщения идентификатор на елемента, който е бил деклариран, например `poem', `title' и т. н. Както ще покажем по-нататък, възможно е да се декларират няколко елемента в едно твърдение.

5.2. Правила за минимизиране

Втората част от декларация определя правилата за минимизиране (minimization rules), които се изискват за съответния елемент. Тези правила определят дали да присъства, или не началният и краен етикет на разглеждания елемент при всяко негово срещане. Те приемат формата на двойка знаци, разделени от празно пространство, първият от които се отнася към откриващия, а вторият - към закриващия етикет. И в двата случая трябва да има минус или буква О („omissible" или „optional"); минусът показва, че етикетът трябва да присъства, а буквата О — че може да бъде пропуснат. Така че в нашия пример всеки елемент с изключение на <line>, трябва да има начален етикет. Само елементите <poem> и <anthology> трябва да имат също така и крайни етикети.

5.3. Модел на съдържанието

Третата част на всяка декларация, затворена в кръгли скоби, се нарича модел на съдържанието (content model) на елемента, защото указва какво по правило може да съдържа този елемент при различните му срещания. Елементното съдържание се указва чрез тармини на други елементи или като се използват специални запазени думи. Съществуват няколко такива запазени думи, от които в обща употреба особено често е #PCDATA, както е и в този пример. Това е съкращение на parsed character data, (множество от знаци, на които е направен смислов разбор) и то означава, че дефинираният елемент може да съдържа всякаква валидна знакова информация. Ако една SGML декларация бъде представена образно като структура на родословно дърво, с един-единствен общ прародител на върха (в ташия случай това би би била <anthology>), тогава почти винаги, ако проследим надолу клоните на дървото (например от <anthology> към <poem> към <stanza> към <line> или <title>), евентуално ще се насочим към #PCDATA. В нашия пример така са дефинирани <title> и <line>. Тъй като техните модели на съдържание указват само #PCDATA и не назовават вмъкнати елементи, те може да не съдържат никакви вмъкнати елементи.

5.4. Индикатори на срещанията

Декларацията за <stanza> в примера по-горе заявява, че строфата съдържа един или повече редове. Тя използва индикатор на срещанията (occurrence indicator) - знака плюс, за да посочи колко пъти може да се срещне елементът, наименуван в нейния модел на съдържание. В синтаксиса на SGML има три индикатора на срещания, обикновено представени от знака плюс, въпросителен знак и звездичка.6 Знакът плюс означава, че има едно или повече срещания на съответния елемент; въпросителният знак означава, че може да има най-много едно или вероятно няма никакво срещане; звездичката означава, че съответният елемент може да липсва или би могъл да се появяви един или повече пъти. Така, ако моделът на съдържание за <stanza> е (LINE*), става възможно да има строфи без редове, така както и такива с повече от един ред. Ако тя бе (LINE?), тогава празни строфи пак биха били допустими, но нито една строфа не може да има повече от един ред. Декларацията за <poem> в примера по-горе установява, че <poem> не може да има повече от едно заглавие, но може да няма и никакво, или че трябва да има най-малко една <stanza>, а може да има и няколко.

5.5. Свързвания на групи

Моделът на съдържание (TITLE?, STANZA+) съдържа повече от един компонент и поради това трябва допълнително да се определя редът, в който тези елементи (<title> и <stanza>) могат да се появяват. Това подреждане се определя от свързванията на групи (the comma) — запетая, използвана между нейните компоненти. Съществуват три възможни свързвания на групи, обикновено представени от запетая, вертикална черта и амперсанд (&). 7

Запетаята означава, че компонентите, които свързва, трябва и двата да се срещат в реда, установен в модела на съдържанието. Амперсандът показва, че компонентите, които свързва, трябва да се появят и двата, но може да го направят във всякакъв ред. Вертикалната черта показва, че само един от компонентите, които свързва, може да се появи. Ако в нашия пример заменим запетаята с един амперсанд, заглавието ще може да се появи или преди строфите на <poem>, или в края (но не между строфите). Ако заменим запетаята с наклонена черта, тогава <poem> ще се състои от заглавие или само от строфи - но не и двете!

5.6. Групи от модели

Досега в нашия пример компонентите на всеки модел на съдържание бяха или единствени елементи, или #PCDATA. Обаче е напълно възможно да се дефинират модели на съдържание, в които компонентите са списък от елементи, комбинирани по свързвания на групи. Такива списъци, известни като групи от модели (model groups), също могат да бъдат модифицирани чрез обозначавания на срещания и, на свой ред, да се комбинират със свързвания на групи. За да демонстрираме тази възможност, нека сега разширим нашия пример и включим безстрофен тип поезия. За по-голяма яснота ще категоризираме поемите като строфни (stanzaic), куплетни, или двустишни (couplets) и такива, съставени от бели (blank, също stichic) стихове. Белият стих се състои просто от редове (за момента игнорираме възможността за стихотворни абзаци)8, така че не е нужно да се дефинират допълнителни елементи за това.

Един куплет (двустишие) се дефинира като <line1>, следван от <line2>.

<!ELEMENT couplet O O (line1, line2) >

Елементите <line1> и <line2> , (които например се различават, за да стане възможно да се изучава схемата на римите,) имат точно същия модел на съдържание, какъвто е на съществуващия <line> елемент. Следователно те могат да споделят една и съща декларация. В тази ситуация е по-удобно да се добави група имена (name group) като първи компонент в декларацията на единичен елемент, отколкото да се даде серия от декларации, отличаващи се само по използваните имена. Една група от имена е списък от GI, съединени чрез всяко свързване на група и и затворени в кръгли скоби като:

<!ELEMENT (line | line1 | line2) O O (#PCDATA) >

Сега декларацията за елемента <poem> може да бъде променена така, че да включва и трите възможности:

<!ELEMENT poem - O (title?, (stanza+ | couplet+ | line+) ) >

Така че поемата се състои от възможно заглавие, следвано от една или няколко строфи; или един или няколко куплета; или един или няколко реда. Забележете разликата между тези определения и следващото:

<!ELEMENT poem - O (title?, (stanza | couplet | line)+ ) >

Вторият вариант - прилагане на обозначение на срещанията към групата, вместо към всеки елемент вътре в нея, би позволил на една отделна поема да съдържа в себе си смесица от строфи, куплети и бели стихове.

По този начин може лесно да се построяват доста сложни модели, да се съчетава структурната сложност на много и различни видове текст. Като следващ пример, отнасящ се до случая със стихотворение от строфи, в което се появява рефрен (повторение - refrain). Рефренът може да е съставен от повторения на елементът ред, а може да е просто текст, който не е разделен на стихове. Рефренът може да се появи само в началото на поемата, или като възможно допълнение, следващо всяка строфа. Това може да се изрази най-добре чрез модела на съдържание, който следва:

<!ELEMENT refrain - - (#PCDATA | line+)>

<!ELEMENT poem - O (title?, ((line+) | (refrain?, (stanza, refrain?)+ ) )) >

Тоест поемата се състои от възможно заглавие, следвано или от последователни редове, или от неназована група, която започва с възможен рефрен, следван от едно или повече срещания на друга група, всеки от членовете на която се състои от строфа, следвана от възможен рефрен. Последователност като „рефрен-строфа-строфа-рефрен" следва този образец, както го прави и последователността „строфа-рефрен-строфа-рефрен". Обаче последователността „рефрен-рефрен-строфа-строфа" не следва образеца, нито пък прави това последователността „строфа-рефрен-рефрен-строфа". Сред другите условия, определени от този модел на съдържание, са изискванията в поемата да има най-малко една строфа, ако то не е съставено просто от редове, и че ако са налице заглавие и строфа, те трябва да се появят в този ред.

2. В момента се работи по създаването на дефиниция за семантика за стиловете на документа и спецификация на този език или DSSSL (Document Style Semantics and Specification Language вече е стандарт на ISO. Елементи на този език могат да се видят в предложените от W3 консорциума препоръки, като XPATH, XSLT и CSS — бележка на редактора)

3. Всъщност символите, използвани като ограничители (ъглови скоби, наклонена черта, възклицателен знак), може да бъдат и други, но е по-удобно да се използват посочените в това описание.

4. Примерът е взет от Songs of innocence and experience на Уилям Блейк, 1794 г. Маркирането е само примерно и не отговаря на TEI.

5. Забележете, че този прост пример не взима под внимание проблема с явното обозначаване на такива елементи като изреченията; последствията от това се разглеждат по-долу в раздел 6.

6. Освен като ограничители, тези обозначения имат формални имена и може да бъдат преопределяни с описание, съответстващо на SGML.

7. Също както ограничителите и обозначенията за срещания, свързванията в описвания стандарт имат формални имена и може да бъдат преопределяни според описание, съответстващо на SGML.

8. Проницателният читател ще забележи факта, че стихотворните абзаци не започват обезателно на границата на строфите, което сериозно усложнява положението; вж. по-нататък раздела Конкурентни структури