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

Series Traductiones, Vol. 1, 2007

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 ..." с любезното съгласие на проф. Лу Бърнард, за което сърдечно му благодарим.

Това е отделното издание на българския превод така, както сме обещали още от първия брой. До края на годината се надяваме да публикуваме и пълния превод на „Gentle Introduction to XML“ от същите автори.

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

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

Внимателно въведение в SGML

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Структури на `SGML`

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

3.1. Елементи

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

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

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

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

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

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

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

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

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

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

       <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>

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

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

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

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

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

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

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

4.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' и т. н. Както ще покажем по-нататък, възможно е да се декларират няколко елемента в едно твърдение.

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

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

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

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

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

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

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

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

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

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

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

Един куплет (двустишие) се дефинира като <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?)+ ) )) >

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

5.Изданието се усложнява: още за декларациите на елементите

В опростените примери, които описахме досега, се предполагаше, че може лесно да се определят най-преките съставни части на всеки елемент, дефиниран в дадена текстова структура. Една поема съдържа строфи, а една антология включва поеми. Строфите не са „свободно плаващи“ наоколо, несвързани с поемите или комбинирани в някакъв друг несвързан елемент; една поема не може да съдържа в себе си антология. Всички елементи в даден тип документ може да бъдат подредени в йерархична структура, подобно на родословно дърво, с единствен прародител на върха и много деца (най-вече елементи, съдържащи #PCDATA) – в основата. Това крайно опростяване се оказва изненадващо ефективно за много голям брой от търсените цели. Обаче то не е адекватно на цялостната сложност в реалните текстови структури. В частност то не се „справя“ със случая на повече или по-малко „свободно плаващи“ елементи, които може да се срещнат на почти всяко йерархично ниво в структурата, а същото важи и за случай, където различни елементи се препокриват или може да бъдат открити няколко различни „дървета“ в един и същи документ. За да се справи с първия случай, SGML предоставя механизма на изключенията (exception), а за втория – позволява да се дефинира „конкурентна“ структура на документа.

5.1. Изключения в модела на съдържание

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

За дасе справи с това, SGML на всеки модел на съдържание да бъде модифициран и по-нататък посредством списъка на изключенията (exception list). Има два типа изключения: включващи (inclusions ), тоест добавъчните елементи, които може да бъдат включени към всяка точка от групата модели или към всеки от нейните съставни елементи; и изключващи (exclusions),т.е. елементи, които не могат да се включват в текущия модел.

За да разширим нашите декларации, ние първо трябва да прибавим декларации за два елемента, като по този начин подложим възможните анотации и варианти на различен прочит. Идеята е да позволим те да се появяват навсякъде в текста на поемата,:

      <!ELEMENT (note | variant) - - (#PCDATA)>

Елементите бележка (пояснителна бележка – анотация, note) и вариант (variant) трябва да имат откриващ и закриващ етикет, тъй като могат да се появяват навсякъде. За да не се налага да ги прибавяме към моделите на съдържанието за всеки тип поема, можем да ги добавим под формата на списък на включванията към елемента поема, която сега ще се чете така:

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

Знакът плюс в началото на списъка с имена (NOTE|VARIANT) показва, че това е „включващо“ изключение. С това допълнение пояснителните бележки или вариантите могат да се появяват във всяка точка в съдържанието на елемента поема – дори в тези елементи (като например <title>), за които вече сме дефинирали модел на съдържанието #PCDATA. Така че и те могат да се появяват вътре в пояснителните бележки или вариантите.

Ако по някаква причина желаем да предотвратим появата на пояснителни бележки или варианти вътре в заглавия, можем да прибавим „изключващо“ изключение (exclusion exception) към декларацията <title> по-горе:

      <!ELEMENT title - O (#PCDATA) -(note | variant) >

Знакът минус в началото на списъка с имена (NOTE|VARIANT) показва, че това става дума за изключване. С това допълнение на пояснителните бележки и вариантите ще бъде забранено да се появяват вътре в заглавия, без да се взема под внимание тяхното потенциално включване, подразбиращо се от предната добавка към модела на съдържание за <poem>.

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

      <!ELEMENT (note | variant) - - (#PCDATA) -(note | variant) >

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

5.2. Конкурентни структури

Всички структури, които обсъдихме досега, бяха просто йерархични, т.е. на всяко ниво на „дървото“, всеки възел изцяло се съдържаше в „родителския “ възел. Диаграмата по-долу представя структурата на документ, съответстващ на прост DTD, който ние вече дефинирахме като „дърво“ (за да спестим място, то е нарисувано странично). Вече видяхме как поемата на Блейк може да бъде разделена на заглавие и две строфи, всяка от които – на четири реда. В тази диаграма ще прибавим втора поема, състояща се от една строфа и заглавие, за да създадем пример (екземпляр) на антологията.

          |-------------------title
          |
          | |----line1
          | |----line2 
          |------POEM1---|----stanza1---|----line3 
          | | |----line4 
          | | 
          | | |----line5 
          | |----stanza2---|----line6 
          | |----line7 
          | |----line8 
anthology-| 
          | 
          | |-------------------title 
          | | 
          | | |----line1 
          | | |----line2 
          |------POEM2---|----stanza1---|----line3 
          |----line4 
          |----line5

Става ясно, че може да се нарисуват много такива „дървета“, за да се опише структурата на тази или друга антология. Някои от тях може да се представят чрез по-нататъшно подразделяне „клоните“ на това дърво: например можем допълнително да разделим редовете на отделни думи, докато думите не пресекат края на реда. Но не по-малко ясно е, че съществуват много други дървета, които могат да се нарисуват и НЕ могат да се вместят в посоченото дърво. Можем например да се заинтересуваме от синтактичните структури – които рядко се съобразяват с формалните граници на стиховете. Или, за да дадем прост пример – може да поискаме представяне чрез отделни страници на различни редакции, третиращи един и същи текст. Един начин да се постигне това, в настоящия ни модел може да бъде групирането на редове и заглавия – в страници. Декларацията за такъв елемент е достатъчно проста:

      <!ELEMENT page - - ((title?, line+)+) >

Тоест страницата се състои от една или повече неназовани групи, всяка от които съдържа възможно заглавие, следвано от последователност редове. (Забележете – това, че моделът забранява на своето заглавие да се появи в долна част на страницата, е случайно.) Обаче простото вмъкване на елемент <page> във вече изградена йерархия съсвем не е така просто, както изглежда. Някои поеми са по-дълги от една страница, а други страници съдържат повече от една поема. Следователно ние не можем да вмъкнем елемента <page> между <anthology> и <poem> в тази йерархия, нито пък това може да стане между <poem> и <stanza>, нито още и на двете места едновременно! Това, което ни трябва, е възможността да се създаде отделна йерархия със същите елементи на дъното (строфи, редове и заглавия), но комбинирани в различна суперструктура. Тази възможност е предоставена от свойството CONCUR на SGML.

Трябва да се създава отделна DTD за всяко йерархично дърво, в което текстът е структуриран. Дефиницията, която съставихме досега за антологията, като цяло изглежда така:

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

Както показва този пример, името на типа на документа трябва винаги да бъде същото като името на най-големия елемент в него – това е елементът на върха на йерархията. Използваният синтаксис е разгледан по-нататък (вж. раздел 9.2.).

Нека сега да добавим към тази декларация второ определение за конкурентен тип на документа, който ще наречем странирана антология, за по-кратко – <p.anth>.

<!DOCTYPE p.anth [
      <!ELEMENT p.anth - - (page+) >
      <!ELEMENT page - - ((title?, line+)+) >
      <!ELEMENT (title|line) - O (#PCDATA) >
      ]>

Сега ние определихме два различни начина, по които да разглеждаме един базов текст – компонентите PCDATA, групирани чрез тези две определения за документен тип, в редове или заглавия. От една гледна точка, редовете са групирани в строфи и поеми, от друга – те са групирани само в страници. Забележете, че това е точно същият текст, който се разглежда и от двете гледни точки: двете йерархии просто ни позволяват да го преподреждаме по два различни начина.

За да маркираме двете гледни точки, ще е необходимо да обозначим към коя йерархия принадлежи всеки един елемент. Това се прави чрез присвояване на име на документния тип (изглед) в кръгли скоби точно преди самия идентификатор, вътре както в началния, така и в крайния етикет. Така страниците (които са видими само в документен тип <p.anth>) трябва да бъдат обозначени с етикета <(p.anth)page> в началото им, и </(p.anth)page – в края. По същия начин, тъй като поемите и строфите се появяват само като документен тип <anthology>, те вече трябва да бъдат маркирани чрез използване съответно на етикетите <(anthology)poem> и <(anthology)stanza>. Обаче за елементите ред и заглавие, които се появяват и в двете йерархии, няма нужда да се правят спецификации на документния тип: всеки етикет, съдържащ само име, по подразбиране маркира елемент, представен във всеки действащ документен тип.

Като един прост пример, нека си представим, че поемата на Блейк се появява в някаква странирана антология, в която краят на страницата се намира в средата на първата строфа. Поемата може да се маркира така:

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

Сега вече е възможно да се избират само елементите, отнасящи се до определена гледна точка от текста, независимо че и двете гледни точки са представени в маркирането. Приложение, интересуващо се само от разделянето на страници, ще вижда само тези елементи, чиито етикети включват спецификацията P.ANTH или изобщо нямат спецификации. Приложение, интересуващо се само от гледната точка ANTHOLOGY върху нещата, няма да вижда прекъсванията на страниците. И приложение, интересуващо се от взаимовръзката между двете гледни точки, може да върши това ясно и недвусмислено.

Тук е уместно едно предупреждение: CONCUR е само възможно свойство, опция на SGML, и не всички налични SGML софтуерни системи го поддържат, а тези, които го поддържат, не го правят винаги в съответствие с „буквата“ на стандарта. Поради тази причина, ако няма друго, когато настоящото ръководство открива потенциално приложение на CONCUR, то едновременно с това настойчиво препоръчва и алтернативни методи. За по-пълно обсъждане на тези въпроси вижте глава 31. Отбележете също, че не можем да въведем един нов елемент, например номер на страница, в типа документ <p.anth>, тъй като в документния тип <anthology> няма съществуваща информация, която би могла да се помести в него. Един от начините да се добави такава допълнителна информация е обсъден в следващия раздел.

6. Атрибути

В контекста на SGML думата „атрибут“ (attribute), като някои други думи, има специфичен технически смисъл. Тя се използва за описание на информацията, която в някакъв смисъл е описателна за специфично срещане на даден елемент, но не се разглежда като част от неговото съдържание. Пример за това е, ако искате да добавите атрибута status към срещанията на някои елементи в документ, за да се обозначи тяхната степен на достоверност или за да се добави атрибутът identifier, така че да можете да направите препратка към определено срещане на елемент, където и да било другаде в документа. Атрибутите са полезни точно при такива обстоятелства.

Макар че различните елементи може да имат атрибути с еднакви имена (в схемата на TEI например всеки елемент е дефиниран така, че да има атрибут id), те винаги се разглеждат като различни и може да имат различни стойности, които им се присвояват. Ако един елемент е дефиниран като притежаващ атрибути, стойностите на атрибута се задават в екземпляра на документа като „двойки атрибут-стойност“ (attribute-value pairs) вътре в началния етикет за срещането на елемента. Един краен етикет може да не съдържа спецификацията атрибут-стойност, тъй като това би било излишно.

Например:

      <poem id=P1 status="draft"> ... </poem>

Елементът <poem> е дефиниран като притежаващ два атрибута: id и status. За екземпляра <poem> в този пример, представен с многоточие, атрибутът id има стойност P1 и атрибутътstatus има стойност draft. Програма с SGML може да използва стойностите на атрибутите по всякакъв избран от нея начин, например оформителят може да отпечата елемент <poem>, който има атрибут status,присвоен на draft по начин, различаващ се от елемент със същия атрибут, присвоен на revised; друга програма може да използва същия атрибут, за да определи дали изобщо да се процедира с елементите <poem>. Атрибутът id е малко по-особен случай, тъй като, по общоприето правило, той винаги се използва за присвояване на уникална стойност с цел идентифициране на отделно срещане на елемент, което може да се използва за целите на кръстосани препратки, както ще разгледаме по-нататък.

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

Следващите декларации може да се използват за дефиниране на два атрибута, които посочихме по-горе за елемента <poem>:

      <!ATTLIST poem
      id ID #IMPLIED
      status (draft | revised | published) draft >

Декларацията започва със символа ATTLIST, който въвежда спецификация на списъка с атрибути (attribute list specification). Неговата първа част посочва елемента (или елементите), за които се отнася. В нашия пример атрибутите бяха декларирани само за елемента <poem>. Ако няколко елемента поделят едни и същи атрибути, всички те може да бъдат декларирани в една-единствена декларация; точно както и при декларациите за елементи, списъкът с няколко имена може да бъде даден в кръгли скоби. Това име (или списък от имена) е последвано от серия редове, по един – за всеки деклариран атрибут, като всеки ред съдържа три части. Те определят име на атрибута, тип на стойността, която приема, и съответно – стойността по подразбиране.

Имената на атрибути (в този пример – id и status) са подложени на същите ограничения както другите имена в SGML; обаче няма нужда те да бъдат уникални в рамките на цялата DTD, а само в списъка от атрибути за даден елемент.

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

CDATA. Стойността на атрибута може да съдържа всяка валидна знакова информация; етикетите може да са включени в стойността, но те няма да бъдат разпознати от SGML парсър (синтактично-морфологически анализатор) и няма да се обработват по начина, по който нормално това се прави с етикетите.
IDREF. Стойността на атрибута трябва да съдържа указател към някой друг елемент (вж. обсъждането на ID по-долу).
NMTOKEN. Стойността на атрибута е именен символ (name token, използва се също и идентификатор), това е (повече или по-малко) всеки ред от цифрово-буквени знаци.
NUMBER. Стойността на атрибута е съставена само от цифри.

В горния пример беше даден списък от възможните стойности за атрибута status. Това означава, че един синтактично-морфологически анализатор (парсър) може да провери и установи, че не е дефинирана <poem>, за която атрибутът status няма някоя от draft, revised или published като своя стойност.

Друга възможност – ако декларираната стойност е била или CDATA, или NAME, синтактично-морфологичният анализатор (парсър) би приел почти всеки низ от знаци (status=“awful“ или status=“12345678“, ако е бил NMTOKEN; status="anything goes", ако status = "well, ALMOST anything", ако е бил CDATA). Разбира се, понякога групата възможни стойности не може да се дефинират предварително. Когато това е възможно, както е в този случай, общо взето е по-добре да се постъпи точно така.

Последната част от всяка информация във всяка дефиниция на атрибут определя как синтактично-морфологичният анализатор би трябвало да интерпретира липсата на съответстващ атрибут. Това може да се направи чрез прибавяне на някоя от специалните ключови думи, изброени в списъка по-долу, или (както е в този случай) чрез присвояване на специфична стойност, която вече се разглежда като стойност за всеки елемент, който не добавя такава за съответстващия атрибут. Като използваме горния пример, ако поемата просто има етикет <poem>, синтактично-морфологичният анализатор ще я третира точно така, сякаш е с етикет <poem status=“draft“>. При друго положение може да се използва някоя от следните ключови думи за определяне на стойност по подразбиране на даден атрибут:

#REQUIRED. Трябва да бъде определена стойност.
#IMPLIED. Не е задължително да бъде присвоявана стойност (както в случая с ID по-горе).
#CURRENT. Ако не е присвоена стойност в дадената поява на елемента, трябва да бъде използвана последната му присвоена стойност.

Например, ако напишем отново дефиницията на атрибута по-горе като

      <!ATTLIST poem
      id ID #IMPLIED
      status (draft | revised | published) #CURRENT >

тогава поемите, появяващи се в антологията просто с етикет <poem>, биха били третирани така, сякаш имат същия статус както и предишните поеми. Ако ключовата дума е #REQUIRED вместо #CURRENT, анализаторът (парсър) ще докладва, че такива поеми са с погрешно поставени етикети, както би станало и ако е била присвоена всяка друга стойност, освен draft, published или revised. Употребата на #CURRENT означава, че каквато стойност е присвоена на съответния атрибут в първата поема, такава ще се прилага и във всички следващи поеми, докато не бъде заменена с нова стойност. Следователно, ако всички поеми са еднакви, достатъчно би било да се зададе единствено статусът на първата поема.

Понякога е необходимо да се направи връзка от появата на един текстов елемент към някой друг, като очевиден пример за това са фрази като „вж. бележка 6“ или „както бе обсъдено в глава 5". Когато се подготвя текстът, действителните номера на бележки или глави може още да не съответстват. Ако използваме описателно маркиране (обозначаване), неща като страници или номера на глави, бивайки изцяло обект на представяне, няма във всеки случай да са представени в маркирания текст: те ще бъдат прибавени от която и да било програма, обработваща текста (и може истински да се отличават при различните приложения). Поради това SGML предоставя специален механизъм, чрез който към всяко срещане на елемент може се даде специален идентификатор, един вид – етикет, който може да се използва за връзка към елемента отвсякъде другаде в рамките на същия текст. Сама по себе си кръстосаната препратка се разглежда като срещане на елемент от особен вид, който също трябва да бъде деклариран в DTD. Във всеки случай идентифициращият етикет (който може да е условен и произволен) се прибавя като стойност на специален атрибут.

Да предположим например, че искаме да вмъкнем препратка между бележките на една поема, която да се отнася и към друга поема. Първо ще ни трябва някакъв начин да прикрепим етикет към всяка от поемите: това се прави чрез дефиниране на атрибута за елемента <poem> както бе предложено по-горе.

      <!ATTLIST poem
      id ID #IMPLIED >

Тук дефинираме атрибут id, стойността на който трябва да бъде от типа ID. Не се изисква за всеки атрибут от типа ID да има също и име id; обаче това е универсално общоприето правило, което почти винаги се прилага. Забележете, че не всяка поема трябва да носи атрибут id и синтактично-морфологичният анализатор (парсър) може спокойно да пренебрегне липсата на такъв. Само в поеми, към които искаме да направим препратка, трябва да използваме този атрибут; необходимо е във всяка такава поема да вмъкнем някакъв уникален идентификатор в нейния начален етикет, например:

      <POEM ID=“Rose“>
      Текст на поемата с идентификатор 'ROSE'
      </POEM>
      <POEM ID=“P40“>
      Текст на поемата с идентификатор 'P40'
      </POEM>
      <POEM>
      В тази поема няма идентификатор
      </POEM>

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

     <!ELEMENT poemref - O EMPTY >
     <!ATTLIST poemref target IDREF #REQUIRED >

Елементът <poemref> не се нуждае от краен етикет, защото няма съдържание. Той има единичен атрибут, наречен target. Стойността на този атрибут трябва да бъде от типа IDREF (ключова дума, използвана за указателите на кръстосана препратка от този тип) и трябва да бъде присвоена.

Използвайки тези декларации, ние вече можем да кодираме препратката към поемата с id Rose, както следва:

     Поема на Блейк за болната роза <POEMREF TARGET=“Rose“> ...

Когато един синтактично-морфологичен анализатор (парсър) на SGML открие този празен елемент, той просто ще провери дали съществува елемент с идентификатор Rose. Други програми със SGML могат да предприемат разнообразни допълнителни действия: оформителят може да състави съвършено точна препратка към страница и ред в определено място от поема, намираща се в текущ документ, и да ги вмъкне в него; а може и просто да цитира заглавието на поемата или първите редове.

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

7. Обекти на `SGML`

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

      <!ENTITY tei "Text Encoding Initiative">

определя обект с име tei, чиято стойност е низът „Text Encoding Initiative“. ⁹Това е пример за декларация на обект (entity declaration), която декларира вътрешен обект (internal entity). Обратно на това следващата декларация декларира системен обект (system entity):

      <!ENTITY ChapTwo SYSTEM "sgmlmkup.txt">

Това определение дефинира външен обект с име ChapTwo, чиято стойност е текстът, асоцииран със системния идентификатор – в този случай системният идентификатор е името на файла на операционната система и заместващият текст на обекта е съдържанието на файла.¹⁰

По своята природа системните идентификатори са зависими от системата, затова, за да се ограничат размерите на информацията, като цяло SGML предоставя и друг начин за именуване на външни обекти:

     <!ENTITY p3.sg PUBLIC "-//TEI//TEXT Guidelines Chapter on SGML//EN" >

SYSTEM е заменен от PUBLIC и системният идентификатор е заменен от публичен идентификатор (public identifier). По принцип последният може да приеме всякаква форма; обикновено се използва формата, показана по-горе (известна още като формален публичен идентификатор – formal public identifier), в която наклонените черти „//“ разделят идентификатора на следните части:

TEI. Показва притежателя на този публичен идентификатор (често, но без да е задължително, притежателят на информация e под въпрос); предшестващият знак „–“ сигнализира, че отделният идентификатор на притежател не е регистриран по стандарт на ISO (знакът „+“ би могъл да означава, че не може да бъдат открити пълното име и адреса на притежателя от официалния регистър на идентификаторите на притежатели).
TEXT. Ключова дума, показваща природата на обекта: други приети стойности са DOCUMENT (за пълен SGML документ), DTD (за определяне типа на документа), ELEMENTS (за набори от декларации на елементи), ENTITIES (за набори от декларации на обекти) и за известен брой притежатели, които са нужни по-рядко и няма да разглеждаме тук.
Глава с указания на SGML . Дава описателно име на обект.
ENе езиков код по ISO стандарта за езика, на който е написан съответният обект.

Публичните идентификатори спомагат SGML документите да станат по-малко зависими от отделните компютърни системи, но те изискват SGML системите да осигуряват механизми за извличане на тези уникални публични идентификатори, които съответстват на файловите идентификатори или други системни идентификатори. (Към сегашния момент, като такъв механизъм се използва най-широко форматът Отворен каталог на SGML, който частично е описан по-долу в раздел 9.4.)

След като веднъж вече обектът е деклариран, към и от него може да се прави препратка навсякъде в рамките на документа. Това се постига, като пред името му се поставя знакът амперсанд „&“, а след него – точка и запетая. Вторият знак може и да се пропусне, ако препратката към обекта е следвана от интервал (празно пространство) или край на записването.

Когато SGML синтактично-морфологичният анализатор (парсър) открие такава препратка към обект(entity reference), той незабавно замества стойността, декларирана за име на обекта. Така изразът „Работата по &tei; току-що започна“ ще се интерпретира от SGML програма точно така, сякаш се чете „Работата по Text Encoding Initiative току-що започна". В случая когато имаме външен обект, това, разбира се, е съдържанието на файла на операционната система, който е заместен, така че изразът „Следващият текст бе пропуснат: &ChapTwo; ще бъде разширен, за да включи всичко, което системата открие във файла sgmlmkup.txt."

Очевидно това спестява писане и опростява задачата по поддържане на последователността и плътността в набор от документи. Ако отпечатването на сложен документ се извършва на много места, основната част на такъв документ може да използва като препратка към обект, като например site; навсякъде където се изисква името на мястото. Тогава различните декларации за обект може да се добавят към различни места, за да захранят съответния низ, който да бъде заменен вместо съответното име, без да се налага промяна на текста в самия документ.

Механизмът за заместване на низове (string substitution) има и много други приложения. Може да се използва за избягване на известната неспособност на много компютърни системи да представят пълния обем от графични знаци, необходими за показването на съвременния английски език (да не говорим за изискванията на други съвременни азбуки или на древни езици). До така наречените „специални знаци“ няма пряк достъп от клавиатурата (или ако има, не са точно транслирани при преноса) може да бъдат представени чрез препратка към обект.

Да предположим например, че искаме да кодираме употреба на лигатура (свързани знаци – по дефиниция: знак, съдържащ две или повече букви, комбинирани в една) в стари печатни текстове. Лигатурната форма „ct“ може да се различава от нелигатурната, като се кодира във вида &ctlig;, вместо като ct. Други специални елементи като късите и дълги тирета (а също и т. нар. „лийфстопс"), може също да бъдат представени добре чрез „мнемонична “ препратка към обект в текста. Когато се обработва такъв текст, една декларация за обект може да се добави, давайки желаното представяне за такива текстови елементи. Ако например лигатурни букви не представляват интерес, можем просто да добавим декларация като:

      <!ENTITY ctlig "ct" >

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

Списъкът от декларации за обект е известен като набор от обекти (entity set). Стандартните набори от обекти са налични за работа в повечето SGML програми, в които използваните имена обикновено са взети от списък с такива имена, публикуван като допълнение към SGML стандарта, както бе споменато по-горе.

Стойностите на замяна, дадени в декларацията на обект, са, разбира се, твърде силно зависими от системата. Ако знаците, които трябва да се използват, не може да бъдат директно набрани, SGML осигурява механизъм за спецификация на знаци по техните числови стойности, известен като препратки на знаци (character references). Препратката към знак се отличава от останалите знаци в замествания низ поради обстоятелството, че започва със специален знак, обикновено – поредицата „&#“, и завършва с нормален знак точка и запетая. Например, ако оформителят представи лигатурата форма „ct“ чрез знаците „c“ и „t“, предхождани от знак на десетична стойност 102, декларацията за обект ще се чете:

      <!ENTITY ctlig "fct" >

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

Една особена форма на обектите – параметрични обекти (parameter entities) може да се използва вътре в SGML маркиращи декларации; те се различават от обсъдените по-горе обекти (известни са като общи обекти (general entities)) по две неща:

Параметричните обекти се използват само в маркиращи декларации на SGML; освен някои особени изключения, които няма да обсъждаме тук, те обикновено не може да се открият в самия документ;
Параметричните обекти се ограничават от знака за процент „%“ и точка и запетая „;“, а не със знака амперсанд „&“ и точка и запетая „;".

Декларациите за параметрични обекти приемат същата форма както тези за общи обекти, но вмъкват знакът „%“ между ключовата дума ENTITY и името на самия обект. От двете страни на знака „%“ трябва да се оставя празно пространство (интервал, табулатор или прекъсване на ред). Един вътрешен параметричен обект с име TEI.prose и разширение INCLUDE, и външен параметричен обект с име TEI.extensions.dtd, който се отнася до системния файл mystuff.dtd, би трябвало да се декларира така:¹¹

      <!ENTITY % TEI.prose 'INCLUDE'>
      <!ENTITY % TEI.extensions.dtd SYSTEM 'mystuff.dtd'>

Определението на TEI за документен тип разширява употребата на параметрични обекти, за да контролира избирането на различни набори от етикети и за да прави по-лесно модифицирането на TEI DTD. Голям брой примери за тяхната употреба може да се открият в глава 3.

8. Маркирани (обозначени) секции

За по-специална обработка от синтактично-морфологичния анализатор (парсър) на SGML понякога е удобно да се обозначават отделни части от текста. Например може да е необходимо някои части от юридически изрази да бъдат систематично включвани или изключвани, в зависимост от някакъв щат или държава, за които трябва да бъде валиден съответният документ. (Тогава може твърдението „Ограничена отговорност до $ 50 000“ да бъде включено в щата Делауер, но да се изключи в Мериленд.) Техническите указания за съответни продукти може да имат една и съща основна обща част информация, но да се различават по някои подробности; може да е удобно в един-единствен документ да се поддържа цялата информация за пълния набор от свързани продукти, като се подбират и показват или отпечатват само тези части, които се отнасят до конкретен продукт. (Така обсъждането на това как да се смени маслото в колата може да използва един и същи текст за повечето действия, но да предложи различен съвет за смяната на карбуратора в зависимост от специфичния модел на двигателя.) За такива случаи SGML осигурява маркирани секции (marked section), конструирани да се справят с изискванията на различните документи. Общо взето, както се примерът по-горе се опита да предложи, това е по-очевидно приложим при създаването на нови текстове, отколкото при кодирането на вече съществуващи. Повечето потребители на кодиращата схема TEI никога не ще трябва да ползват маркирани секции и могат, ако желаят, да прескочат останалата част от това обсъждане. Обаче в определенията за документен тип на TEI има широка употреба на маркирани секции и този раздел трябва внимателно да се прочете и разбере от всеки, който желае да детайлно да проследи дискусията в глава 3.

„Специалната обработка“, предлагана от маркираните секции в SGML, може да бъде от няколко типа, всеки от които се свързва с една от следните ключови думи:

INCLUDE. Маркираната секция трябва да бъде вмъкната в документ и да се обработи нормално.
IGNORE. Маркираната секция трябва да бъде изцяло пренебрегната, ако SGMLпрограмата извежда изходни данни от документа, маркираната секция ще бъде изключена от него.
CDATA. Маркираната секция може да съдържа низове от знаци, които изглеждат като SGML етикети или препратки към обекти, но които не може да бъдат разпознати като такива от SGML синтактично-морфологичен анализатор (парсър). (Това ръководство използва такива CDATA маркирани секции, за да затвори примерите с поставяне на SGML етикети).
RCDATA. Маркираната секция може да съдържа низове от знаци, изглеждащи като SGML етикети, но които не може да бъдат разпознати като такива от SGML синтактично-морфологичния анализатор (парсър); от друга страна, препратките към обекти може да присъстват и ще бъдат разпознавани и разширявани както обикновено.
TEMP. Пасажите, включващи маркирани секции, са временна част от документа; маркираната секция се използва преди всичко за указване на тяхното местоположение, така че да може по-късно, когато е удобно, те може да бъдат премахвани или преразглеждани.

Когато в текста се срещне маркирана секция, тя се обработва от началния низ на маркираната секция (marked-section start string), който съдържа една или повече ключови думи от горния списък; краят ù е обозначен от затварящия низ на маркиращата секция (marked-section close string). Вторият и последният ред от следващия пример са начало и край на игнорирана маркирана секция:

      В такива случаи банката ще възстанови на клиента всички негови загуби.
      <![ IGNORE [
      Отговорността е ограничена до $50,000.
      ]]>

От ключовите думи за маркирани секции най-важните за доброто разбиране на TEI DTD са INCLUDE и IGNORE; те може да бъдат използвани избирателно за включване и изключване на части от документ или от DTD, така че да се приспособят към съответните условия (т.е. да позволят на потребителя да избере части от DTD, съответни за дадения документ).

Обаче буквалната употреба на ключовите думи INCLUDE и IGNORE не върши много работа при приспособяването на DTD или на документа към изискванията на потребителя. (Например за да се измени показаният по-горе текст така, че да включи изключвания израз, на потребителя ще се наложи да редактира ръчно и да смени IGNORE с INCLUDE. Също толкова лесно би било просто да се добавя или изтрива някакъв израз на ръка.) Но не е задължително ключовите думи да бъдат дадени като буквални стойности; те може да бъдат представени чрез препратка към параметричен обект. Например в документ с много текст, който трябва да бъде включен само в щата Мериленд, всяко изречение може да бъде включено в маркирана секция, чиято ключова дума е представена чрез препратка към параметричен обект, наречен Maryland. Тогава горният пример би бил:

      В такива случаи банката ще възстанови на клиента всички негови загуби.
     <![ %Maryland; [
     Отговорността е ограничена до $50,000.
     ]]>

Когато обектът Maryland е дефиниран като IGNORE, всички така обозначени маркирани секции ще бъдат изключени. Маркираните секции ще бъдат включени в документа, ако бъде променена дефиницията за следното:

      <!ENTITY % Maryland 'INCLUDE'>

Когато параметричните обекти се използват по този начин, за да контролират маркираните секции в DTD, външният DTD файл обикновено съдържа декларацията по подразбиране. Ако потребителят желае да не се съобрази с нея (например чрез включване на секции за Мериленд), добавянето на съответната декларация за поднабора DTD ще е достатъчно, за да се „прескочи“ тази по подразбиране.¹²

Сега вече можем по-добре да разберем примера за декларациите на параметричен обект от края на предшестващия раздел. Декларациите

      <!ENTITY % TEI.prose 'INCLUDE'>
      <!ENTITY % TEI.extensions.dtd SYSTEM 'mystuff.dtd'>

имат ефект на включване в DTD на всички секции, обозначени като отнасящи се за проза, тъй като във външни DTD файлове всички такива секции са включени в маркирани секции, контролирани от параметричния обект TEI.prose. Те също така „прескачат“ декларацията по подразбиране TEI.extensions.dtd (която декларира този обект като празен низ), така че обектът включва файла mystuff.dtd в DTD.

9. Да обобщим нещата

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

Един SGML документ съдържа SGML пролог и екземпляр на документа (document instance). Прологът съдържа SGML декларация (SGML declaration,описана по-долу)и определяне типа на документа (document type definition), което съдържа декларации за елемента и обекта като описаните по-горе. Отделните софтуерни системи могат да предлагат различни начини на свързване на документния екземпляр и пролога; в някои случаи прологът може да бъде така вграден в използвания софтуер, така че да е напълно невидим за потребителя.

9.1. `SGML` декларация

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

9.2. `DTD` – определение за тип на документа

Определението за тип на документа дефинира тип на документа, по отношение на когото се проверява валидността на документния екземпляр. Също както SGML декларацията, DTD може да се съхраняват под формата на съставни таблици вътре в SGML обработваща програма или да са свързани вътре в нея по някакъв начин, невидими за потребителя; или може да изискват само да бъде посочено името на документния тип, преди самият документ да бъде проверен за валидност.

В своя най-опростен вид определението за тип на документа се състои само от базово определение за типа на документа (възможно е също да има едно или повече конкурентни определения за типа на документа), което предхожда екземпляра на документа. Например:

       <!DOCTYPE my.dtd [ 
       <!-- всички декларации за MY.DTD почват оттук --> 
       ... 
       ]> 
       <my.dtd> 
       Това е екземпляр на документ от типа MY.DTD  
       </my.dtd>

По-обичайно е определението за тип на документа да се съхранява в отделен файл и дасе извиква чрез препратка както е показано:

       <!DOCTYPE tei.2 PUBLIC "-//TEI P3//DTD Main Document Type//EN">
       <tei.2>
       Това е екземпляр на немодифициран TEI тип на документ
       </tei.2>

Тук текстът на TEI.2 определението за тип на документа не е дадено изрично, но SGML програмата „казва“, че той може да се прочете от файла със системния идентификатор, даден в кавички. Пак може да се добавят квадратни скоби, както е в този пример, дори ако те не затварят нищо.

Частта, затворена от квадратни скоби, е известна като набор декларации за тип на документа (document type declaration subset) или DTD набор. Основната му цел е да посочва всички изменения, направени в извикваното DTD определение:

       <!DOCTYPE tei.2 PUBLIC "-//TEI P3//DTD Main Document Type//EN" [ 
       <!ENTITY tla "Трибуквеносъкращение"> 
       <!ELEMENT my.tag - - (#PCDATA)> 
       <!—тук почват всички специални декларации или 
       изменени определения --> 
       ]> 
       <tei.2>

       Това е екземпляр на документ от модифициран тип TEI.2,
       който може да съдържа <my.tag>специални етикети</my.tag> и
       препратки към обичайни обекти като &tla;.
       </tei.2>

В този случай определението за типа на документа включва, първо, съдържанието на DTD поднабора, а после – съдържанието на файла, посочен след ключовата дума SYSTEM. Това подреждане е важно, защото в SGML се отчита само първата декларация на обект. Следователно в горния пример декларацията на обект tla в DTD поднабор ще има предимство пред всяка декларация на същия обект във файла tei2.dtd. В SGML е напълно нормално обектите да се декларират двукратно; това е обичайният метод да се разреши на потребителя модифициране на DTD в SGML. (За разлика от това елементите не може да се декларират повече от веднъж; ако декларацията за <my.tag> се съдържа във файла tei.dtd, анализаторът (парсър) на SGML ще съобщи за грешка.) Съчетаването и разширяването на TEI определенията за тип на документ са обсъдени по-нататък – в глава 3.

9.3. Екземпляр на документа

„Екземпляр“ на документа е съдържанието на самия документ. Той съдържа само текст, маркиране (обозначаване) и общи препратки към обект, така че не може да съдържа в себе си никакви нови декларации. Удобен начин за изграждане на големи документи от модулен вид може да бъде употребата на DTD поднабор за деклариране на обекти за индивидуални части от модулите ето така:

       <!DOCTYPE tei.2 [ 
       <!ENTITY chap1 system "chap1.txt"> 
       <!ENTITY chap2 system "chap2.txt"> 
       <!ENTITY chap3 "—още не е написано --"> 
       ]> 
       <tei.2> 
       <teiHeader> ... </teiHeader> 
       <text> 
       <front> ... </front> 
       <body> 
       &chap1; 
       &chap2; 
       &chap3; 
       ... 
       </body> 
       </text> 
       </tei.2>

В този пример DTD определението, съдържащо се във файла tei2.dtd, е било разширено чрез обектните декларации за всяка глава в творбата. Първите две са външни обекти, свързани с файла, в който се намира текстът с текущите глави; третият е „фалшив“ и показва, че текстът още не съществува (би могло да се използва и обект с нулева стойност). В екземпляра на документ, на препратките към обект &chap1; и т. н. ще бъдат разрешено от анализатора да дадат търсеното съдържание. Разбира се, файловете с главите от текста няма да съдържат никакви елементи, списък с атрибути или декларации за обекти – а само маркиран текст.

9.4. Помощни файлове

В практиката работещите с SGML системи ползват известен брой спомагателни файлове, в които се съхранява конфигурационна информация. Форматиращите страници (Style sheets), (засега в обща употреба повече е специфичното за софтуера форматиране, отколкото стандартното форматиране, което с течение на времето би трябвало да получи много по-широко разпространение), файлове със специализирани процедурни инструкции, файлове с информация за първоначална настройка за отделните програми – всичко това ще бъде необходимо в практическата работа с SGML. Много програми също така използват променливи за средата, отнасящи се към някои части от настройката им (например „казват“ на програмата къде да намери конфигурационните си файлове). Подробностите относно това какви файлове са необходими и как влияят те върху работата на една SGML система, варират според системата и не може да бъдат разгледани тук.

По-новият SGML софтуер използва стандартен формат, наречен SGML формат на Отворения каталог (SGML Open Catalog format, вж. бел. 16) за каталожни файлове (catalog files), използвани, за да помагат на SGMLсинтактично-морфологичния анализатор (парсър) да открива файлове (или мрежови източници), съответстващи на публичните или системни идентификатори, използвани в декларациите на обекти (и в други SGML построения). Каталожен файл, използващ този формат, може да съдържа въвеждания (entries) за всеки публичен идентификатор в DTD, във форми като тази:

       PUBLIC "-//TEI P3//DTD Main Document Type//EN"
       "teifpi2.dtd"

Всяко въвеждане има три части: ключова дума PUBLIC, публичен идентификатор и системен идентификатор, под които SGML анализаторът може да открие обекта, именуван чрез публичния идентификатор.

Един файл от отворения каталог с въвеждания за всяка част от TEI DTD е достъпен от TEI. За повече информация вижте глава 36.

10. Работа с `SGML`

В момента е достъпен разнообразен софтуер, спомагащ за решаване на задачи по създаване, проверяване (валидиране) и обработване на SGML документи. Тук можем да опишем само няколко от базовите типове. В самата основа на по-голямата част от този софтуер е SGML синтактично-морфологичният анализатор (парсър): това е програмен модул, който може да вземе определението за тип на документа и да създаде от него софтуерна система, способна да проверява (валидира) всеки документ, извикващ такъв DTD. В най-елементарния случай излизането от анализатора е чрез „Yes“ (екземплярът на документа е валиден) и „No“ (ако не е такъв). Обаче повечето анализатори създават и нова версия на екземпляра на документа в канонична форма ( canonical form ), (в която обикновено са добавени всички крайни етикети и са разрешени всички препратки към обекти) или форматират в съответствие със спецификациите на потребителя. След това тази форма може да бъде използвана от други части на програмата (по-широко или по-тясно свързани с анализатора) за осъществяване на допълнителни функции като структурно редактиране, форматиране и управление на база данни.

Структурният редактор (structured editor) е вид интелигентна текстообработваща програма. Тя може да използва информацията, извлечена от обработен DTD, за да насочи потребителя относно това кои елементи се изискват в различните места на документа, докато е създаван самият документ. Тя също така може да опрости в огромна степен задачата по подготовката на документа, например чрез автоматично вмъкване на етикети.

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

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

Хипертекстовите системи подобряват други методи за обработване на текст чрез поддържане на асоциативни връзки вътре в документите, както и помежду им. Отново посочваме – основният градивен блок, нужен за такива системи, е също и базов градивен блок на SGML маркирането: освобождава се способността да се идентифицират и свързват заедно отделните елементи на даден документ; тя е част от начина, по който SGML върши нещата. Чрез явното обозначаване на връзките, вместо използването на собствени програми, разработчиците на хипертекстове може да са сигурни, че ресурсите, които създават, ще продължат да бъдат приложими. За да се вкара SGML в хипертекстова система, се изисква само програма, която точно интерпретира SGML етикети като тези, разгледани в глава 14.

Notes / Бележки

1. International Organization for Standardization, ISO 8879: Information processing---Text and office systems---Standard Generalized Markup Language (SGML), ([Geneva]: ISO, 1986)

* Споменатите тук и по-нататък в изложението глави от авторите се отнасят до пълната версия на TEI Guidelines P3. Тя може да бъде открита на страниците на консорциума (TEI.)

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 стандарта е просто свързване. По-дългият термин тук е шредпочетен за наблегне на факта, че тези свързвания се използват само в моделните групи на SGML . Също както ограничителите и обозначенията за срещания, свързванията в описвания стандарт имат формални имена и може да бъдат преопределяни според описание, съответстващо на SGML

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

9. Разликата между големи и малки букви е важна по условие при имената на обектите, за разлика от имената на елементите.

10. Строго погледнато, SGML не изисква системните (руският превод упорито нарича системни обекти външните –(external)обекти. При дефинирането им разлика не бе посочена, нито основания за това. Бел. моя) обекти да са файлове; по принцип те могат да бъдат всякакви източници на данни, достъпни за SGML програма: файлове, резултати от запитвания към бази данни, резултати от изисквания на системните функции – каквото и да било. Обаче при изучаването на SGML е по-просто да се представят системните (external)обекти с препратки към файлове и настоящото обсъждане по-нататък пренебрегва други възможности. Всички съществуващи програми с SGML поддържат използването на системни (external)обекти за препратки към файлове; малко са тези, които разрешават други възможни използвания на системни (external)обекти

11. Подобни декларации на обекти се използват за разширение на базовия набор от елементи TEI за проза чрез декларации, намиращи се в mystuff.dtd.

12. Това е така, защото декларацията в поднабора DTD се прочитат по-рано от тези, които се съдържат във файла DTD, а в сила е декларацията, която се счита за първа. Това накратко е описано в раздела Обекти на SGML.

Форма за търсене

Littera et Lingua