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

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.

4.1. Елементи

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

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

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

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

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

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

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

4.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>5

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

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

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

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

5.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?)+ ) )) >

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