|
Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
|
|
Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
Определение структуры документов SGML - DTD
Рассмотренные правила—первый шаг в создании формальной спецификации структуры SGML-документа или определения типа документа, обычно сокращаемого, как DTD ( Document Type Definition ). При создании DTD дизайнер произвольно задает жесткую или сколь угодно гибкую структуру. Нужно найти компромисс между удобством следования простым правилам и сложностью поддержки реальных текстов. Это особенно важно, когда определяемые правила относятся к уже существующим текстам: дизайнер может иметь очень туманное представление об изначальном предназначении или смысле старых текстов, поэтому задание непротиворечивых правил, касающихся их структуры, будет крайне сложным. С другой стороны, при спецификации нового текста, например, для ввода в некоторую базу данных, чем точнее установлены правила, тем лучше они могут быть выдержаны. Даже в случае разметки уже существующего текста имеет смысл ограничивающий набор правил, относящихся к его определенному прочтению, — хотя бы как средство проверки своего мнения. Каждое определение типа документа является интерпретацией текста. Не существует единственного DTD, охватывающего все сведения о тексте, несмотря на удобство предпочтения одних DTD другим для конкретных типов анализа. В настоящее время SGML шире всего применяется там, где основным требованием служит единообразие структуры документов. Например, при производстве технической документации весьма важно, чтобы разделы и подразделы были соответствующим образом вложены, перекрестные ссылки производились корректно и т. д. В таких ситуациях к документам относятся, как к сырому материалу, к которому применяется заранее определенный набор правил. Однако, как говорилось выше, простые правила могут сильно упростить задачу аккуратной разметки элементов и менее ограниченных текстов. Делая правила явными, исследователь уменьшает свою работу по разметке и проверке, в то же время выявляя интерпретацию структуры и значимые особенности кодируемого текста. Пример DTD DTD в SGML выражается в виде набора описательных утверждений с использованием определенного в стандарте простого синтаксиса. Для нашей модели технического руководства подойдут следующие описания: <! ELEMENT manual — (system+)> <! ELEMENT system — (systitle?, subsystem+)> <! ELEMENT subsystem — (subsystitle?, topic+)> <! ELEMENT topic — О (topictitle?, paragraph+)> <! ELEMENT systitle — О (#PCDATA)> <! ELEMENT subsystitle — О (#PCDATA)> <! ELEMENT topictitle — О (#PCDATA)> <! ELEMENT paragraph — О (#PCDATA)> 220 УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ ПРОДУКЦИИ
Первая часть описания определяет обобщенный идентификатор описываемого элемента, например, manual, system и т. д. Как будет показано ниже, в одном утверждении можно описывать несколько элементов. Правила минимизации Вторая часть описания задает правила минимизации для элемента. Они определяют обязательность открывающей и закрывающей меток для каждого появления данного элемента и имеют вид пары символов, разделенных пробелом, где первый символ относится к открывающей, а второй — к закрывающей метке. В обоих случаях должны присутствовать или минус или буква О; минус означает, что метка обязана быть, а буква О — что ее можно опустить. Модель содержимого Третья часть каждого описания, заключенная в круглые скобки, называется моделью содержимого элемента. Она указывает, что входит в экземпляры элемента. Содержимое описывается либо в терминах других элементов, либо при помощи специальных зарезервированных слов. Есть несколько таких зарезервированных слов, из которых самое часто используемое — #PCDATA. Это сокращение от «parsed character data» (разобранные символьные данные), оно означает, что описываемый элемент может включать любые разрешенные символьные данные. Если представить себе SGML-описание в виде структуры наподобие генеалогического дерева с одним предком наверху (в нашем случае < тапиа> \ то почти всегда, следуя по ветвям дерева вниз (например, от < manuat > к < system >, < subsystem >, < topic >, < paragraph > ), мы придем к #PCDATA. В нашем примере так определены < systUle >, < subsystitle >, < topictitle > и < paragraph >. Так как в их модели содержимого указано только #PCDATA и не названо никаких включаемых элементов, они не содержат других элементов. Обозначения включения Вышеприведенное описание для < manuat > устанавливает, что руководство состоит из одной или более систем. Оно использует обозначение включения (occurence indicator) — зцак плюс — для указания того, сколько раз может встречаться элемент, названный в модели содержимого. В синтаксисе SGML есть три Связки Модель содержимого элемента system (systitle?, subsystem+) содержит больше одного компонента. Поэтому нужно дополнительно указать порядок, в котором они (< systitle > и < subsystem > ) могут появляться. Это упорядочение определяется связкой (group connector) между компонентами. Существуют три возможные связки, представляемые запятой, вертикальной чертой и знаком «& ». (Так же как ограничители и обозначения включения, связки имеют в стандарте формальные имена и могут быть переопределены соответствующим SGML-описанием.) Запятая означает, что оба компонента, которые она соединяет, должны встречаться в порядке, указанном в модели содержимого. Знак «& » обозначает, что два компонента встречаются в произвольном порядке. Вертикальная черта показывает, что мы увидим только один из компонентов, которые она соединяет. Если в нашем примере запятую заменить на знак «& », то заголовок появится или перед подсистемами, или после них (но не между). Если ее заменить на вертикальную черту, то система будет состоять или из заголовка, или только из систем (но не из того и другого). Атрибуты В контексте SGML слово атрибут (attribute), подобно другим, имеет строгий технический смысл. Оно используется для информации, в каком-либо смысле описательной для конкретного элемента, не являющейся частью его содержимого. Например, можно добавить атрибут status к экземплярам некоторых элементов для обозначения степени их достоверности или атрибут identifier, чтобы ссылаться на появление элемента из других мест документа. Атрибуты полезны именно в таких случаях. Хотя несколько элементов могут иметь атрибуты с одинаковыми названиями, такие атрибуты всегда считаются различными и обладают различными значениями. Если элемент имеет атрибуты, их значения задаются в документе как пары «атрибут - значение» внутри открывающей метки экземпляра элемента. Закрывающая метка не может содержать спецификаций «атрибут - значение», так как это было бы излишним. Например: < system id = 214.030.000.00 status = «drafb»... < /system>. 222 УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ ПРОДУКЦИИ
Как и элементы, атрибуты описываются при объявлении типа документа с употреблением довольно похожего синтаксиса. Кроме спецификации названия атрибута и элемента, к которому он относится, можно указать (в некоторых границах), какие виды значений приемлемы для атрибута и каковы они по умолчанию. Для определения двух атрибутов, указанных у элемента < system >, используют следующие объявления: <! ATTLIST system id ID#IMPLIED status (draft | revised | published) draft>. Объявление начинается с символа ATTLIST, который открывает специфика цию списка атрибутов (attribute list specification). Первая его часть указывает рассматриваемый элемент (или элементы). В нашем примере атрибуты объявляются только для элемента < system >. Если несколько элементов имеют одни и те же атрибуты, все они могут быть определены в одном объявлении. Для этого, точно так же как и в объявлениях элементов, нужно задавать в круглых скобках список из нескольких названий. За названием (или списком) следует набор строк, где объявляются по одному атрибуты; каждое объявление содержит три части. Они соответственно обозначают название атрибута, тип принимаемых им значений и значение по умолчанию. Названия атрибутов ( id и status в нашем примере) подпадают под те же ограничения, что и другие идентификаторы в SGML; однако они должны быть уникальны не в пределах всего DTD, а только в списке атрибутов данного элемента. Вторая часть спецификации атрибута может принимать одну из двух рассмотренных выше форм. В первом случае используется одно из нескольких ключевых слов, объявляя тип значений, принимаемых атрибутом. В примере фигурирует специальное ключевое слово ID, показывающее, что атрибут id будет применен для указания уникального идентифицирующего значения каждой системы. Рассмотрим другие ключевые слова SGML. CDATA Значение атрибута может содержать любые разрешенные символьные данные. В него входят метки, но их не распознает синтаксический анализатор SGML, и они не будут обрабатываться как обычно. IDREF Значение атрибута в обязательном порядке указывает на некоторый другой элемент (см. дальнейшее обсуждение//)). Значение атрибута является идентификатором (name token), то есть (более или менее) произвольной строкой алфавитно-цифровых символов. NUMBER Значение атрибута состоит только из цифр. В предыдущем примере был задан список возможных значений атрибута status. Синтаксический анализатор может убедиться, что в документе нет < system > со значением атрибута status не из draft, revised или published. Либо, если это значение CDATA или NAME, анализатор будет принимать почти любую строку символов (status = awful или status = 12345678 при значении NMTOKEN; status = «сойдет что попало» или status = «ну, ПОЧТИ что попало», если оно было CDATA ). Конечно, иногда набор возможных значений нельзя определить заранее. Последняя часть информации в каждом определении атрибута указывает, как анализатор должен интерпретировать отсутствие рассматриваемого атрибута с помощью одного из нижеперечисленных ключевых слов или (как в данном случае) конкретного значения, которое трактуется по умолчанию. В нашем примере, если система размечена, как < system >, анализатор будет считать его < system status = " draft " >. В ином случае значение по умолчанию для атрибута может быть указано при помощи одного из следующих ключевых слов. « REQUIRED Значение должно быть указано. « IMPLIED Значение не обязано быть указано (как в случае с ID выше). « CURRENT Если значение не указано, следует использовать последнее из обозначенных. Например, если вышеприведенные определения атрибутов переписать в виде <! ATTLIST system id ID #IMPLIED status (draft | revised | published) #CURRENT>, то системы, названные в руководстве < system >, будут трактоваться аналогично статусу предыдущей системы. Если вместо « CURRENT употребить ключевое слово « REQUIRED, анализатор будет считать такие системы ошибочно размеченными или значение будет отличаться от draft, published или revised. Использование « CURRENT подразумевает, что значение, указанное для него в первой системе, применяется ко всем следующим, пока его не заменят. Следовательно, когда статусы всех систем одинаковы, его нужно обозначить только у первой. Иногда необходимо в одном элементе сослаться на другой, очевидными примерами чего служат фразы «см. замечание 6» или «как указано в главе 5». Во время подготовки текста действительные номера, соответствующие замечаниям или главам, могут быть не определены. Если мы используем описательную разметку, такие вещи как номера страниц или глав, будучи целиком и полностью вопросом представления, ни в коем случае не присутствуют в размеченном тексте: они будут присвоены приложением, обрабатывающим текст (и часто отличаются в разных приложениях). SGML предоставляет специальный механизм, с помощью которого экземпляру любого элемента можно присвоить идентификатор (вроде метки), кото- 224 УПРАВЛЕНИЕ ЖИЗНЕННЫ М ЦИКЛОМ ПРОДУКЦИИ рый применяется для ссылок на него из любого другого места текста. Перекрестная ссылка сама по себе является элементом специального вида, он также должен быть объявлен в DTD. В любом случае идентифицирующая метка (которая может быть произвольной) указывается в качестве значения специального атрибута. Предположим, что мы хотим из одной системы сослаться на другую. Сначала нужно присоединять метку к каждой из них определением атрибута для элемента < system >, как рекомендовано выше. <! ATTLIST system id ID #IMPLIED> Здесь мы определяем атрибут id, значение которого должно быть типа ID. Название id для типа ID не является обязательным. Однако это удобное соглашение, которому практически всегда следуют. Заметим, что не каждая система должна нести атрибут id, и анализатор свободно игнорирует его отсутствие. Только те системы, на которые мы собираемся ссылаться, нуждаются в его использовании. В открывающую метку каждой такой системы мы должны включить некоторый уникальный идентификатор, например: < SYSTEM ID = ПОО (Текст ситемы с идентификатором «ПОС».) < /SYSTEM>; < SYSTEM ID = 214.030.000.00> (Текст системы с идентификатором «214.030.000.00».) < / SYSTEM>; < SYSTEM> (У этой системы нет идентификатора.) < / SYSTEM>. Далее мы определим новый элемент для перекрестных ссылок. Он не будет иметь содержимого — являясь только указателем, он содержит атрибут, значением которого служит идентификатор указываемого элемента. Это достигается следующим объявлением: <! ELEMENT systemref — О EMPTY> <! ATTLIST systemreftarget IDREF #REQUIRED>. Элемент < systemref > не нуждается в закрывающей метке, так как у него нет содержимого, что указывается в модели с помощью ключевого слова EMPTY (пустой). Его единственный атрибут— target, чей тип значения IDREF (ключевое слово, используемое для перекрестных указателей такого типа) обязан быть указанным. Используя эти объявления, мы можем закодировать ссылку на систему с id 214.030.000.00 следующим образом: Описание работы противообледенительной системы < S YSTEMREF TARGET = 214.030.000.00>... Когда анализатор SGML дойдет до пустого элемента, он просто проверит существование элемента с идентификатором 214.030.000.00. Различные SGML-приложения предпринимают разнообразные дополнительные действия: форматировщик может сконструировать точную ссылку на номер страницы и строки описания системы в текущем документе и вставить ее или просто процитировать заголовок, а также Объекты SGML Обсуждавшиеся до сих пор аспекты SGML имели отношение к разметке структурных элементов документа. SGML также предоставляет простой и гибкий метод кодирования и наименования произвольных частей содержимого документа. В SGML слово объект (entity) несет специальный смысл: оно означает именованную часть размеченного документа безотносительно к структуре. Объектом могут быть строка символов или целый файл текста. Для включения его в документ используется конструкция, известная как ссылка на объект (entity reference). Например, следующее объявление <! ENTITY pos «Противообледенительная система»> определяет объект pos, значением которого является строка «Противообледенительная система». (По соглашению названия объектов бывают чувствительными к регистру в отличие от названий элементов.) Это был пример объявления объекта (entity declaration), которое обозначает внутренний объект (internal entity). Следующее объявление, напротив, указывает системный объект (system entity): <! ENTITY ChapTwo SYSTEM «sgmlmkup.txb». Здесь определяется системный объект ChapTwo, значением которого служит текст, ассоциированный с системным идентификатором. В этом случае системный идентификатор — имя файла операционной системы. Текст замещения объекта является содержимым файла. После того как объект объявлен, на него можно ссылаться в любом месте документа. Это делается путем использования его названия, перед которым ставится символ «& », а после — точка с запятой. Точка с запятой может быть опущена, если за ссылкой на объект следуют пробел или конец записи. Когда SGML-анализатор встречает ссылку на объект, он немедленно подставляет вместо названия объекта нужное значение. Так, фраза «схема защищаемых участков самолета от обледенения и размещение агрегатов & pos показаны на рис. 2» будет интерпретирована SGML-процессором так, как если бы это было — «схема защищаемых участков самолета от обледенения и размещение агрегатов противообдеденительной системы показаны на рис. 2». В системном объекте подставляется содержимое файла операционной системы. Фраза «следующий текст был опущен: & ChapTwo; » будет включать все, что система найдет в файле sgmlmkup.txt. Строго говоря, SGML не требует, чтобы системные объекты были файлами. Они могут в принципе быть любыми источниками данных, доступными SGML-процессору: файлами, результатами запросов к базе данных, результатами вызовов системных функций и т. д. Однако при изучении SGML проще представлять себе системные объекты ссылающимися на файлы, и настоящее обсуждение далее игнорирует прочие возможности. Все существующие SGML-процессоры поддерживают использование системных объектов для ссылок на файлы; лишь некоторые учитывают другие их возможности. 226 УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ П РОДУКЦИИ Это, очевидно, экономит время и упрощает проблему непротиворечивости набора документов. Если печать сложного документа происходит во многих местах, тело документа может использовать ссылку на объект (такую как & site; ) там, где требуется название места. Затем можно добавить разные объявления объектов для подстановки вместо нее соответствующего названия, не меняя текст самого документа. Механизм строковой подстановки имеет много применений. Его можно использовать для ликвидации неравенства компьютерных систем в представлении полного диапазона символов английского алфавита (не говоря уже о требованиях других современных или древних языков). Так называемые «специальные символы», напрямую не доступные с клавиатуры (или неправильно транслируемые при передаче), указываются ссылкой на объект. Предположим, что мы хотим закодировать использование лигатур в старых печатных текстах. «Лигированная» форма ct должна отличаться от нелигирован-ной путем кодирования ее (как & ctlig; ), а не в виде ct. Прочие специальные типографские элементы (вроде линеек или leafstops) точно так же обозначены, как мнемонические ссылки на объекты. При обработке текстов будет добавлено объявление объектов, и мы получим желаемое представление подобных элементов текста. Если, например, лигированные буквы интереса не представляют, мы можем просто добавить объявление вида <! ENTITY ctlig «ct»>, и различие в исходном документе будет снято. Когда используется форматирующая программа, способная представить лигированные символы, заменим объявление объекта так, чтобы дать ту последовательность символов, которую требует такая программа. Список объявлений объектов известен как набор объектов (entity set). Стандартные наборы объектов, доступные для большинства SGML-процессоров, обычно включают названия, взятые из списков имен, опубликованных как приложение к стандарту SGML в других местах. Значения подстановок, заданные в объявлениях объектов, конечно, системнозависимы. Если примененные в них символы нельзя набрать напрямую, SGML предоставляет механизм их спецификации по численным значениям— ссылки на символы (character references). Ссылка на символ отличается от остальных символов в строках подстановки тем, что начинается со специального символа (обычно — последовательности & Щ и заканчивается точкой с запятой. Например, если используемый форматировщик представляет лигированную форму ct по символам с и t, предваряемым символом с десятичным значением 102, объявление объекта может выглядеть так: <! ENTITY ctlig «& #102; ct»>. Заметим, что ссылки на символы обычно не имеет смысла переносить между программными или аппаратными платформами, поэтому они применяются только в ситуациях, подобных описанной. Хотя механизм ссылок на объекты и полезен для редких отклонений от ожидаемого набора символов, никто не будет пользоваться им для кодирования длинных предложений, например цитат на греческом или русском в английском тексте. В подобных случаях работают с иными механизмами. 228 > применяются только внутри объявлений SGML-разметки и обычно не встречаются в документе; ^ ограничиваются знаком процента (а не знаком «& ») и точкой с запятой. Объявления параметрических объектов имеют тот же вид, что и объявления обычных, но между ключевым словом ENTITY и названием вставляется знак процента (%), с обеих сторон отделенный пустыми местами (пробелами, табуляциями или переводами строк). Отмеченные секции Иногда удобно отметить некоторые части текста, чтобы SGML-анализатор относился к ним по-особому. Технические руководства для связанных продуктов содержат множество информации, но отличаются в некоторых деталях. Часто информация о целом наборе сходных продуктов находится в одном документе, а в момент показа или печати выбираются только те его части, что относятся к конкретному продукту. (Скажем, описание того, как заменять моторное масло, может использовать один и тот же текст для большинства шагов, но содержать разные советы по удалению карбюратора, зависящие от модели двигателя.) Для подобных случаев SGML предоставляет конструкцию отмеченных секций (marked sections). Она гораздо удобнее при производстве новых текстов, а не при кодировании уже существующих. «Специальная обработка», предлагаемая в SGML для отмеченных секций, бывает нескольких типов, каждый из которых ассоциируется с одним из следующих ключевых слов. INCLUDE Отмеченная секция должна быть включена в документ и нормально обработана. IGNORE Секцию следует целиком проигнорировать; если SGML-приложение генерирует данные на основании документа, она будет из них исключена. CDATA Может содержать строки символов, которые выглядят, как метки SGML или ссылки на объекты, но не должны распознаваться в качестве таковых SGML-анализатором (их используют для включения примеров SGML-разметки). RCDATA Включает строки символов, которые выглядят, как метки SGML, но не распознаются в качестве таковых SGML-анализатором. Ссылки на объекты, с другой стороны, могут присутствовать и будут распознаны и заменены как обычно. TEMP Предложения, входящие в отмеченную секцию, являются временной частью документа. Секция в основном используется для обозначения их положения, чтобы позже они могли быть удалены или пересмотрены. 229 УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ ПРОДУКЦИИ
В таких случаях банк возместит клиенту все потери. <! [ IGNORE [ Ответственность ограничена $50000. ]]> Из ключевых слов наиболее важными являются INCLUDE и IGNORE. Они используются при выборочном включении и исключении частей документа (DTD) для подгонки его под конкретные условия (например, чтобы дать пользователю возможность выбирать части DTD, подходящие нужному документу). Однако буквальное применение ключевых слов INCLUDE и IGNORE не помогает в настройке DTD. (Например, чтобы вставить исключаемую фразу, пользователю нужно будет вручную редактировать текст, сменив IGNORE на INCLUDE. С тем же успехом можно просто убирать или добавлять фразу в текст.) Но ключевые слова не обязаны быть представлены буквальными значениями — они могут быть ссылками на параметрические объекты. Скажем, в документе некоторые фразы, следует включить только в раздел Maryland. Каждая фраза заключается в отмеченную секцию, чье ключевое слово представлено ссылкой на параметрический объект под названием Maryland. В таких случаях банк возместит клиенту все потери. <! [%Maryland; [ Ответственность ограничена $50000. ]]> Когда параметрические объекты таким образом используются для управления отмеченными секциями DTD, внешний файл DTD обычно содержит объявлс ■ ния по умолчанию. Если пользователь хочет это изменить (например, включив секции для Maryland ), достаточно добавить соответствующее объявление в подмножество DTD. (Объявления в подмножестве DTD читаются раньше файлов DTD, а силу имеет объявление, прочитанное первым.) Использование SGML Существует множество программных средств для создания, проверки и обработки SGML-документов. Сердцем большинства продуктов служит синтаксический анализатор SGML, то есть программный модуль, принимающий определение типа и генерирующий систему проверки любого документа с таким DTD. Ответом анализатора в простейшем случае будет «да» (экземпляр документа правилен) или «нет». Большинство анализаторов, кроме того, выдают новую версию документа в канонической форме (canonic form), содержащую добавленные закрывающие метки и разрешенные ссылки на объекты или сформатированную в соответствии с заданием пользователя. Эта форма может быть затем использована другими частями программной системы (более или менее тесно связанными с анализатором) для выполнения дополни- 230 Структурный редактор (structured editor) является интеллектуальным текстовым процессором. Он применяет информацию, выделенную из обработанного DTD, чтобы подсказывать пользователю, какие элементы требуются в разных местах текста в процессе редактирования. Он также может сильно упростить задачу подготовки документа, автоматически вставляя метки. Форматировщик (formatter) использует размеченный экземпляр для генерации его печатной формы. Многие типографские различия набора (начертания шрифта или его размер) тесно связаны со структурными различиями текста, так что форматировщики применяют сведения, заложенные в описательной разметке. Можно, кроме того, определять структуру разметки для форматирующей программы при помощи параллельной структуры документа. Системы управления текст-ориентированными базами данных обычно используют инвертированные индексы, указывающие на документ или его подразделения. Можно организовывать поиск вхождений некоторого слова или образца внутри документа или его части. Осмысленное подразделение входящих документов будет, безусловно, тесно связано с делением, заданным описательной разметкой. Таким образом, системам текстовых баз данных просто работать с размеченными в SGML документами. В настоящее время большое число исследований в области расширения возможностей существующих (нетекстовых) систем управления базами данных проводится для использования преимуществ явной SGML-разметки структурированной информации. Гипертекстовые (hypertext) системы поддерживают ассоциативные связи внутри и между документами. Строительные блоки, необходимые им, являются также и базовыми блоками SGML: возможность идентифицировать и связывать отдельные элементы документа вытекает из методов работы SGML. Явно размечая связи вместо использования закрытого программного обеспечения, авторы гипертекстов могут быть уверены, что создаваемые ими ресурсы надолго останутся доступными. Все, что требуется для загрузки SGML-документа в гипертекстовую систему, — это процессор, умеющий корректно интерпретировать метки SGML. Помимо текстовой и графической информации в SGML-стандарт часто вставлены мультимедийные элементы: аудио- и видеозаписи и клипы. Технология встройки мультимедийных элементов регламентируется специальным расширением SGML, описанным в стандарте ISO 10744 HyTime (Hypermedia/TimeBased Structuring Language) языком «привязки» мультимедийных объектов. 5.2.18. Преимущества SGML Повышение производительности Структурный подход позволяет создателю документа организовать информацию и хранить его содержание отдельно от формата. Это помогает централизованно настроить формат документов, поэтому их авторы могут сосредотачивать свои усилия на содержании, а не на оформлении, что удваивает производительность. 231 УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ ПРОДУКЦИИ |
Последнее изменение этой страницы: 2019-03-29; Просмотров: 384; Нарушение авторского права страницы
Эти восемь строчек — примеры формальных описаний элементов SGML. Описание, как и элемент, ограничено угловыми скобками; первым символом за открывающей скобкой должен быть восклицательный знак, за которым сразу следует одно из ключевых слов, указывающее на тип описываемого объекта. Все восемь описаний имеют одинаковый тип: каждое начинается с ключевого слова ELEMENT, показывающего, что описывается элемент в определенном выше техническом смысле. Описание состоит из трех частей: названия или группы названий; двух символов, задающих правила минимизации (minimization rules), и модели содержимого (content model). Каждая из данных частей рассмотрена ниже. Компоненты описания разделяются «пустым местом», то есть одним или более пробелом, табуляцией или переводом строки.
Элемент < system > содержит два атрибута: id и status. Для экземпляра ' < system >, представленного многоточием, id имеет значение 214.030.000.00, а status — значение draft. SGML-процессор может применять значения атрибутов произвольным образом. Например, форматирование печатает элементы системы со значением атрибута status draft и revised по-разному. Другой процессор; будет использовать тот же атрибут, чтобы определить, нужно ли вообще обрабатывать соответствующие элементы системы. Атрибут «/является особым случаем, так как по соглашению он всегда применяется для снабжения конкретного экземпляра элемента уникальным значением, которое может использоваться для перекрестных ссылок.