Языки разметки SGML и XML

1. SGML — метаязык разметки для документов.

1.1. Особенности SGML. Использование SGML.

1.2. SGML-структуры.

1.3. Атрибуты в SGML. Объекты SGML

2.XML

2.1XML как подмножество метаязыка SGML. Особенности XML. Использование XML.

2.2Принцип построения XML-документов. Конструкции языка

2.3.Логические структуры. Начальные теги, конечные теги и теги пустых элементов. Элементы, объявления типов элементов. Атрибуты, объявления списков атрибутов.

2.4.Физические структуры. Ссылки на символы и на сущности.

2.5.Обработка XML процессором сущностей и ссылок

Язык разметки документов – это набор специальных инструкций, называемых тегами, предназначенных для формирования в документах какой-либо структуры и определения отношений между различными элементами этой структуры. Теги языка, или, как их иногда называют, управляющие дескрипторы, каким-либо образом кодируются в таких документах, они выделяются относительно основного содержимого документа и служат в качестве инструкций для программы, производящей показ содержимого документа на стороне клиента. В самых первых системах для обозначения этих команд использовались символы “ < ” и “ > ”, внутри которых помещались названия инструкций и их параметры. Сейчас такой способ обозначения тегов является стандартным.

1.    SGML — метаязык разметки для документов.

1.1. Особенности SGML. Использование SGML.

SGML — наследник разработанного в 1960 году в IBM языка GML (Generalized Markup Language), который не стоит путать с Geography Markup Language, разрабатываемым Open GIS Consortium.

Изначально SGML был разработан для возможности совместного использования машинно-читаемых документов в больших правительственных и аэрокосмических проектах. Также он широко использовался в печатной и издательской сфере, но его сложность затруднила его широкое распространения для повседневного использования.

Три основные части SGML документа, это

1. SGML декларация;
2. Document Type Definition;
3. Содержимое SGML-документа, по крайней мере, должен быть корневой элемент.

      Существуют три характеристики SGML, отличающие его от других языков разметки: его упор на описательную, а не на процедурную разметку; его концепция типа документа (document type); его независимость от конкретной системы в представлении текста.

      Система описательной разметки использует коды разметки, просто предоставляющие названия для классификации частей документа. Коды, такие, как <para> или \end{list} просто идентифицируют часть документа и утверждают про нее: "следующий элемент -- параграф" или "это -- конец начатого последним списка" и т.д. Напротив, система процедурной разметки определяет, какая обработка должна производиться в конкретной точке документа: "здесь вызвать процедуру PARA с параметрами 1, b и x", или "сдвинуть левую границу на 2см влево, правую -- на 2см вправо, пропустить строку и встать на новую левую границу", и т.д. В SGML инструкции, необходимые для обработки документа с определенными целями (например, для его форматирования) четко отделяются от описательной разметки, встречающейся внутри документа. Обычно они собираются вне документа в отдельных процедурах или программах.

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

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

      Раз документы имеют известные типы, можно использовать специальную программу, называющуюся анализатором (parser), для проверки документа, утверждающего свою принадлежность определенному типу. Анализатор проверяет, что все элементы, требуемые типом документа, на самом деле присутствуют и расположены в правильном порядке. Что более важно, разные документы одного и того же типа могут обрабатываться одинаковым образом. Можно конструировать программы, использующие знание структуры документа, которые, таким образом, могут действовать в более осмысленной манере.

      Основная цель создания SGML заключалась в том, чтобы обеспечить транспортабельность закодированных документов из одной аппаратной и программной среды в другую без потери информации. Два описанных выше свойства решают эту задачу на абстрактном уровне; третье свойство -- на уровне строк байтов (символов), из которых составляется документ. SGML предоставляет универсальный механизм строковой подстановки (string substitution), то есть, простой машинно-независимый способ обозначить, что некоторая последовательность символов в документе должна заменяться при его обработке некоторой другой последовательностью. Одно очевидное применение этого механизма -- обеспечение согласованности номенклатуры; другое, и более важное, -- противодействие печально известной неспособности различных компьютерных систем понимать наборы символов друг друга, или способ в любой системе предоставить все графические символы, необходимые для конкретного приложения, путем использования описательных обозначений непереносимых символов. Строки, определенные этим механизмом подстановки, называются объектами (entities) и обсуждаются ниже в разделе Объекты SGML.

1.2. SGML-структуры. Понятие «тип документа», понятие «определение типа документа»  (document type definition, DTD).

Этот раздел описывает простой и согласованный механизм разметки или идентификации структурных единиц текста, предоставляемый SGML. Он также описывает, какие способы SGML предлагает для выражения правил, определяющих возможные осмысленные комбинации этих единиц в любых текстах.

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

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

    ...  реплика Розалинды <quote>Ничего глупее я никогда не

     слышала!</quote> ясно показывает ...

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

      Элемент может быть пустым (empty), то есть, не содержать внутри вообще ничего; элемент может содержать просто текст. Чаще, однако, элементы одного типа будут целиком содержаться (embed) внутри элементов другого типа.

      Возможность использования правил, устанавливающих, какие элементы могут быть вложены в другие, является очень важным свойством SGML. Не переходя к дальнейшему разбору этих правил, можно попытаться рассмотреть, как размеченный вышеприведенным образом текст может быть обработан с различными целями. Простая индексирующая программа может выделять только значимые элементы текста для генерации списка заголовков, или слов, использованных в тексте стихотворения; простая программа форматирования может вставлять пустые строчки между строфами, возможно, начиная с красной строки первую строчку каждой строфы, или вставляя номер строфы. Разные части каждого стихотворения могут набираться разными способами. Более сложная аналитическая программа может соотносить использование знаков пунктуации со строфовыми и метрическими разделами. Исследователи, желающие видеть следствия изменений разделов строф или строк, выбранных редактором этого стихотворения, могут это сделать просто меняя положения меток. И, конечно, представленный выше текст может быть перенесен с одного компьютера на другой и обработан любой программой (или человеком), понимающей смысл внесенных в него меток, безо всяких преобразований и трансляций, необходимых обычно для перемещения файлов текстовых процессоров.

      Правила наподобие вышеописанных -- первый шаг в создании формальной спецификации структуры SGML документа или определения типа документа, обычно сокращаемого как DTD. При создании DTD дизайнер документа может задавать произвольно жесткую или сколь угодно гибкую структуру. Нужно найти компромисс между удобством следования простым правилам и сложностью поддержки реальных текстов. Это особенно справедливо, когда определяемые правила относятся к уже существующим текстам: дизайнер может иметь очень туманное представление об изначальном предназначении или смысле старых текстов, и задание непротиворечивых правил, касающихся их структуры, может быть очень сложным. С другой стороны, когда специфицируется новый текст, например, для ввода в некоторую текстовую базу данных, то чем точнее установлены правила, тем лучше они могут быть выдержаны. Даже в случае разметки уже существующего текста может иметь смысл определить ограничивающий набор правил, относящихся к определенному видению текста или гипотезе, касающейся текста, -- хотя бы как средство проверки полезности этого видения или гипотезы. Важно помнить, что каждое определение типа документа является интерпретацией текста. Не существует единственного DTD, охватывающего все сведения о тексте, хотя может быть удобно предпочитать одни DTD другим для конкретных типов анализа.

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

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

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

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

      Модель содержимого (TITLE?, STANZA+) содержит больше одного компонента. Поэтому нужно дополнительно указать порядок, в котором эти элементы (<title> и <stanza>) могут появляться. Это упорядочение определяется связкой (group connector) -- запятой -- использованным между ее компонентами. Существуют три возможных связки, обычно представляемых запятой, вертикальной чертой и знаком "&". (Так же, как ограничители и обозначения включения, связки имеют в стандарте формальные имена и могут быть переопределены соответствующим SGML описанием.)

      Запятая означает, что оба компонента, которые она соединяет, должны встречаться в порядке, указанном в модели содержимого. Знак "&" указывает, что компоненты, которые он соединяет, должны встречаться оба, но в произвольном порядке. Вертикальная черта означает, что может встречаться только один из компонентов, которые она соединяет. Если бы в нашем примере запятую заменить на знак "&", то заголовок мог бы появляться или перед строфами стихотворения, или в его конце (но не между строфами). Если ее заменить на вертикальную черту, то стихотворение могло бы состоять или из заголовка, или только из строф -- но не из того и другого.

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

<!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?)+ ) )) >

То есть, стихотворение состоит из необязательного заголовка, за которым следует или последовательность строк, или безымянная группа, открывающаяся рефреном, за которым идет одна или несколько других групп, каждый член которой состоит из строфы с необязательным рефреном. Этому образцу отвечает последовательность рефрен - строфа - строфа - рефрен, так же, как и строфа - рефрен - строфа - рефрен. А последовательность рефрен - рефрен - строфа - строфа ему не удовлетворяет, так же, как и строфа - рефрен - рефрен - строфа. Среди прочих условий, накладываемых этой моделью, -- требования, чтобы в стихотворении было хотя бы одна строфа, если оно не состоит просто из строк, и чтобы при наличии и заголовка и строфы они появлялись именно в этом порядке.

1.3. Атрибуты в SGML. Объекты SGML

В контексте SGML, слово атрибут (attribute), подобно другим, имеет строгий технический смысл. Оно используется для описания информации, являющейся в каком-либо смысле описательной для конкретного появления элемента, но не являющейся частью его содержимого. Например, можно добавить атрибут status к экземплярам некоторых элементов для обозначения степени их достоверности, или добавить атрибут identifier, так что можно будет ссылаться на конкретное появление элемента из других мест документа. Атрибуты полезны именно в таких случаях.

      Хотя разные элементы могут иметь атрибуты с одинаковыми названиями (например, в схеме TEI каждый элемент определяется имеющим атрибут id), эти атрибуты всегда считаются различными и могут иметь различные присваиваемые им значения. Если элемент определен имеющим атрибуты, значения атрибутов задаются в документе как пары атрибут-значение внутри открывающей метки экземпляра элемента. Закрывающая метка не может содержать спецификаций атрибут-значение, так как это было бы излишним.

   Обсуждавшиеся до сих пор аспекты SGML все имели отношение к разметке структурных элементов документа. SGML также предоставляет простой и гибкий метод кодирования и наименования произвольных частей действительного содержимого документа переносимым образом. В SGML слово объект (entity) несет специальный смысл: оно означает именованную часть размеченного документа, безотносительно ко всяческим соображениями структуры. Объектом может быть строка символов или целый файл текста. Для включения его в документ используется конструкция, известная как ссылка на объект (entity reference).

2.    XML — расширяемый язык разметки.

2.1. XML как подмножество метаязыка SGML. Особенности XML. Использование XML.

XML (англ. eXtensible Markup Language — расширяемый язык разметки; произносится [экс-эм-э́л]) — рекомендованный Консорциумом Всемирной паутины язык разметки, фактически представляющий собой свод общих синтаксических правил. XML предназначен для хранения структурированных данных (взамен существующих файлов баз данных), для обмена информацией между программами, а также для создания на его основе более специализированных языков разметки (например, XHTML), иногда называемых словарями. XML является упрощённым подмножеством языка SGML.

Целью создания XML было обеспечение совместимости при передаче структурированных данных между разными системами обработки информации, особенно при передаче таких данных через Интернет. Словари, основанные на XML (например, RDF, RSS, MathML, XHTML, SVG), сами по себе формально описаны, что позволяет программно изменять и проверять документы на основе этих словарей, не зная их семантики, то есть не зная смыслового значения элементов. Важной особенностью XML также является применение так называемых пространств имён (англ. namespace).

Достоинства

• XML(человеко-ориентированный) — это формат, одновременно понятный и человеку и компьютеру;
• XML поддерживает Юникод;
• в формате XML могут быть описаны основные структуры данных — такие как записи, списки и деревья;
• XML — это самодокументируемый формат, который описывает структуру и имена полей также как и значения полей;
• XML имеет строго определённый синтаксис и требования к парсингу, что позволяет ему оставаться простым, эффективным и непротиворечивым.
• XML также широко используется для хранения и обработки документов как он-лайн, так и офф-лайн:
• XML — формат, основанный на международных стандартах;
• иерархическая структура XML подходит для описания практически любых типов документов;
• XML представляет собой простой текст, свободный от лицензирования и каких-либо ограничений;
• XML не зависит от платформы;
• XML является подмножеством SGML (который используется с 1986 года). Уже накоплен большой опыт работы с языком и созданы специализированные приложения.
• XML не накладывает требований на расположение символов на строке [1]

Недостатки

• Синтаксис XML избыточен.
• Размер XML документа существенно больше бинарного представления тех же данных. В грубых оценках величину этого фактора принимают за 1 порядок (в 10 раз).
• Размер XML документа существенно больше, чем документа в альтернативных текстовых форматах передачи данных (например JSON [2]) и особенно в форматах данных оптимизированных для конкретного случая использования.
• Избыточность XML может повлиять на эффективность приложения. Возрастает стоимость хранения, обработки и передачи данных.
• Для большого количества задач не нужна вся мощь синтаксиса XML и можно использовать значительно более простые и производительные решения [3]
• XML не содержит встроенной в язык поддержки типов данных. В нём нет понятий «целых чисел», «строк», «дат», «булевых значений» итд
• Иерархическая модель данных, предлагаемая XML, ограничена по сравнению с реляционной моделью и объектно-ориентированными графами
• Выражение не иерархических данных (например графов) требует дополнительных усилий
• Кристофер Дейт отмечал, что «…XML является попыткой заново изобрести иерархические базы данных…» [4] (в 1980-е года иерархические базы данных были вытеснены реляционными базами данных).
• Пространства имён XML сложно использовать и их сложно реализовывать в XML парсерах
• Существуют другие, обладающие сходными с XML возможностями, текстовые форматы данных, которые обладают более высоким удобством чтения человеком (YAML [5] , JSON [6], SweetXML [7])

Использование:

• В первую очередь, эта технология может оказаться полезной для разработчиков сложных информационных систем, с большим количеством приложений, связанных потоками информации самой различной структурой. В этом случае XML - документы выполняют роль универсального формата для обмена информацией между отдельными компонентами большой программы.
• XML является базовым стандартом для нового языка описания ресурсов, RDF, позволяющего упростить многие проблемы в Web, связанные с поиском нужной информации, обеспечением контроля за содержимым сетевых ресурсов, создания электронных библиотек и т.д.
• Язык XML позволяет описывать данные произвольного типа и используется для представления специализированной информации, например химических, математических, физических формул, медицинских рецептов, нотных записей, и т.д. Это означает, что XML может служить мощным дополнением к HTML для распространения в Web "нестандартной" информации. Возможно, в самом ближайшем будущем XML полностью заменит собой HTML, по крайней мере, первые попытки интеграции этих двух языков уже делаются (спецификация XHTML).
• XML-документы могут использоваться в качестве промежуточного формата данных в трехзвенных системах. Обычно схема взаимодействия между серверами приложений и баз данных зависит от конкретной СУБД и диалекта SQL, используемого для доступа к данным. Если же результаты запроса будут представлены в некотором универсальном текстовом формате, то звено СУБД, как таковое, станет "прозрачным" для приложения. Кроме того, сегодня на рассмотрение W3C предложена спецификация нового языка запросов к базам данных XQL, который в будущем может стать альтернативой SQL.
• Информация, содержащаяся в XML-документах, может изменяться, передаваться на машину клиента и обновляться по частям. Разрабатываемые спецификации XLink и Xpointer поволят ссылаться на отдельные элементы документа, c учетом их вложенности и значений атрибутов.
• Использование стилевых таблиц (XSL) позволяет обеспечить независимое от конкретного устройства вывода отображение XML- документов.
• XML может использоваться в обычных приложениях для хранения и обработки структурированных данных в едином формате.

2.2. Принцип построения XML-документов. Общие синтаксические конструкции. Символьные данные и разметка. Разделы CDATA. Объявление типа документа.

В общем случае XML- документы должны удовлетворять следующим требованиям:

• В заголовке документа помещается объявление XML, в котором указывается язык разметки документа, номер его версии и дополнительная информация
• Каждый открывающий тэг, определяющий некоторую область данных в документе обязательно должен иметь своего закрывающего "напарника", т.е., в отличие от HTML, нельзя опускать закрывающие тэги
• В XML учитывается регистр символов
• Все значения атрибутов, используемых в определении тэгов, должны быть заключены в кавычки
• Вложенность тэгов в XML строго контролируется, поэтому необходимо следить за порядком следования открывающих и закрывающих тэгов
• Вся информация, располагающаяся между начальным и конечными тэгами, рассматривается в XML как данные и поэтому учитываются все символы форматирования ( т.е. пробелы, переводы строк, табуляции не игнорируются, как в HTML)

Конструкции языка

Содержимое XML- документа представляет собой набор элементов, секций CDATA, директив анализатора, комментариев, спецсимволов, текстовых данных. Рассмотрим каждый из них подробней.

Пример XML-документа:

<conservatory>

      <flower>rose</flower>

      <flower>tulip</flower>

      <flower>cactus</flower>

</conservatory>

Элементы

Элемент - это структурная единица XML- документа. Заключая слово rose в в тэги <flower> </flower> , мы определяем непустой элемент, называемый <flower>, содержимым которого является rose. В общем случае в качестве содержимого элементов могут выступать как просто какой-то текст, так и другие, вложенные, элементы документа, секции CDATA, инструкции по обработке, комментарии, - т.е. практически любые части XML- документа.

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

<flower>rose</flower>

<city>Novosibirsk</city>

Набором всех элементов, содержащихся в документе, задается его структура, и определяются все иерархическое соотношения. Плоская модель данных превращается с использованием элементов в сложную иерархическую систему с множеством возможных связей между элементами.

Производя в последствии поиск в этом документе, программа клиента будет опираться на информацию, заложенную в его структуру - используя элементы документа. То есть, если, например, требуется найти нужный университет в нужном городе, используя приведенный фрагмент документа, то необходимо будет просмотреть содержимое конкретного элемента <university>, находящегося внутри конкретного элемента <city>. Поиск при этом, естественно, будет гораздо более эффективен, чем нахождение нужной последовательности по всему документу.

В XML документе, как правило, определяется хотя бы один элемент, называемый корневым и с него программы-анализаторы начинают просмотр документа. В приведенном примере этим элементом является <country>

В некоторых случаях тэги могут изменять и уточнять семантику тех или иных фрагментов документа, по разному определяя одну и ту же информацию и тем самым предоставляя приложению-анализатору этого документа сведения о контексте использования описываемых данных. Например, прочитав фрагмент <city>Holliwood</city> мы можем догадаться, что речь в этой части документа идет о городе, а вот во фрагменте <restaurant>Holliwood</restaurant> - о забегаловке.

В случае, если элемент не имеет содержимого, то есть нет данных, которые он должен определять, то он называется пустым. Примером пустых элементов в HTML могут служить такие тэги HTML, как <br> <hr>, <img>. Необходимо только помнить, что начальный и конечные тэги пустого элемента как бы объединяется в один, и надо обязательно ставить косую черту перед закрывающей угловой скобкой (например, <empty/>;)

Имена тегов и атрибутов можно писать и по-русски. Опыт HTML показал, сколь важна тщательная и своевременная интернационализация всех аспектов языка, претендующего на какую-то роль в Интернете. Поэтому создатели XML позаботились, в частности, о том, чтобы в именах тегов и атрибутов можно было пользоваться не только латинскими буквами, но и кириллицей, иероглифами и вообще всеми символами из репертуара Unicode, которые считаются "буквами" хотя бы в одном языке или системе письменности.

Секция CDATA используется для того, чтобы обозначить части документа, которые не должны восприниматься как разметка. Секция CDATA начинается со строки '<![CDATA[' и заканчивается строкой ']]>'. Внутри самой секции не должна присутствовать строка ']]>'.

Секция CDATA:

Cтруктура XML-документа и разбор его XML-процессором позволяют произвести только простую проверку того, что документ является правильно оформленным. Для создания на этой основе специализированных языков необходимы дополнительные средства описания этих языков. XML поддерживает два механизма подобных описаний: определения типа документа (document type definition, DTD) и XML-схемы (XML schema).

2.3. Логические структуры. Начальные теги, конечные теги и теги пустых элементов. Элементы, объявления типов элементов. Атрибуты, объявления списков атрибутов.

Определение: Каждый XML документ содержит один или несколько элементов, границы каждого из которых обозначены либо парой начальный тэг - конечный тэг, либо (если это пустой элемент) тэгом пустого элемента. Каждый элемент имеет определенный тип, который идентифицируется по имени и иногда называется "общим идентификатором" этого элемента (generic identifier - GI), а также может иметь набор спецификаций к атрибутам.] Каждая спецификация атрибута содержит его имя и значение.

Элемент

Данная спецификация не ограничивает семантику, порядок использования (за исключением синтаксиса), выбор имен для атрибутов и типов элементов. Ограничение заключается в том, что имена, чье начало соответствует шаблону (('X'|'x')('M'|'m')('L'|'l')), зарезервированы для стандартизации в текущей и последующих версиях данной спецификации.

Для достижения действительности, на структуру элементов в XML документе могут быть наложены ограничения в виде деклараций типов используемых элементов и списков атрибутов. Декларирование типа элемента накладывает ограничение на его содержание.

Декларация типа элемента часто конкретизирует тип его непосредственных потомков. По выбору пользователя, XML процессор может генерировать предупреждение если в декларации был упомянут тип элемента, для которого не было предоставлено соответствующей декларации, однако ошибочной эта ситуация не считается.

[Определение: Декларация типа элемента имеет вид:]

Декларация типа элемента

где параметр Name определяет декларируемый тип элемента.

Ограничение действительности: Уникальность декларации типа элемента

Ни один тип элемента не может быть декларирован более одного раза.

Атрибут используется для того, чтобы связать с элементом пару имя-значение. Спецификация атрибута может быт дана только в начальном тэге, либо тэге пустого элемента. Таким образом, сценарии ее обработки следует искать в главе 3.1 Начальные тэги, конечные тэги и тэги пустых элементов. Декларация списка атрибутов может быть использована для:

·         формирования перечня атрибутов, относящихся к определенному типу элементов.

·         ограничения по типу атрибутов.

·         формирования значений по умолчанию для атрибутов.

[Определение: для каждого атрибута, относящегося к элементам определенного типа, в соответствующей декларации списка атрибутов определяются имя, тип данных и, возможно, значение по умолчанию:]

Декларация списка атрибутов

В поле Name в правиле AttlistDecl указывается тип элемента. По выбору пользователя, XML процессор может генерировать предупреждение, если атрибуты, декларированные для такого типа элементов, сами декларированы не были, однако ошибкой такая ситуация не считается. Параметр Name в правиле AttDef соответствует имени описываемого атрибута.

Если для какого-либо из типов элементов было дано несколько деклараций AttlistDecl, то содержимое всех их суммируется. Если для некого типа элементов было дано несколько деклараций одного и того же атрибута, то использоваться должна только первая декларация, а все последующие будут игнорироваться. Для сохранения совместимости, авторы DTD могут придерживаться правила давать для любого типа элементов не более одной декларации списка атрибутов, не более одной декларации для каждого имени атрибута, представленного в декларации списка атрибутов и, по крайней мере, одну декларацию атрибута в каждой из деклараций списка атрибутов. В целях совместимости, XML процессор по выбору пользователя может генерировать предупреждение, если для какого-либо типа элементов было представлено более одной декларации списка атрибутов, или для какого-либо атрибута было представлено более одной декларации, однако описанные ситуации ошибочными не являются.

Типы атрибутов

Все типы XML атрибутов делятся на три класса: строковый тип, набор символьных (tokenized) типов и перечислимые (enumerated) типы. Строковый тип может иметь в качестве значения одну строку. Символьные типы содержат различные лексические и семантические ограничения. Ограничения действительности, обсуждаемые в данной грамматике, начинают действовать после того, как значение атрибута было нормализовано в соответствии с описанием в главе

  Декларации списков атрибутов.

Типы атрибутов

2.4. Физические структуры. Ссылки на символы и на сущности. Объявления сущностей. Обработка сущностей и ссылок процессором XML

Определение: XML документ может состоять из одной или нескольких единиц размещения, называемых сущностями. Все сущности имеют содержание (исключение составляют сущность документа и внешний набор DTD) и идентифицируются по имени.] Каждый XML документ имеет ровно одну сущность, называемую сущностью документа, которая служит стартовой точкой для XML процессора и может содержать документ целиком.

Определение: Ссылка на символ относится к определенному символу из набора ISO/IEC 10646, например, к такому символу, который невозможно получить непосредственно с имеющихся устройств ввода.]

Ссылка на символ

Ссылка на сущность

Декларация сущности

Внутренние сущности

[Определение: Если сущность декларирована как EntityValue, то она называется внутренней сущностью. Для этой сущности отсутствует размещаемый отдельно физический объект, а нее содержание определяется в декларации.] Заметим, что в строковом значении сущности для создания приемлемого текста замены может потребоваться некоторая обработка ссылок на сущность и символ: см. главу 4.5 Построение текста замены для внутренней сущности.

Внутренняя сущность является разобранной сущностью.

Пример декларации внутренней сущности:

<!ENTITY Pub-Status "This is a pre-release of the specification.">

Внешние сущности

[Определение: Если сущность не является внутренней, это внешняя сущность, декларируемая следующим образом:]

Декларация внешней сущности

Обработка XML процессором сущностей и ссылок

В представленной далее таблице собраны сведения о контексте, в котором могут появиться ссылки на символы, ссылки на сущность, а также вызовы неразобранных сущностей, и какая в каждом случае потребуется реакция от XML процессора. Записи в левой колонке описывают распознаваемый контекст:

Ссылка в содержимом

Ссылка в любом месте элемента в интервале между начальным и конечным тэгами. Соответствует незавершенному (nonterminal) контенту.

Ссылка в значении атрибута

Ссылка либо в значении атрибута начального тэга, либо в значении по умолчанию из декларации атрибута. Соответствует незавершенному AttValue.

Значение атрибута

Это не ссылка, а лексема типа Name. Выступает либо как значение атрибута, декларированного с типом ENTITY, либо как одна из лексем, перечисленных через пробел в значении атрибута, декларированного с типом ENTITIES.

Ссылка в значении сущности

Ссылка из параметра или строкового значения внутренней сущности, находящихся в декларации сущности. Соответствует незавершенной EntityValue.

Ссылка в DTD

Ссылка во внутреннем или внешнем наборе DTD, не попавшая в конструкции EntityValue, AttValue, PI, Comment, SystemLiteral, PubidLiteral, а также содержимое игнорируемой условной секции (см. главу 3.4 Условные секции).