6. 6
Определение элементов
Декларация элементов
<!ELEMENT имя-элемента категория>
<!ELEMENT имя-элемента (содержимое-элемента)>
Элементы с потомками (последовательности)
<!ELEMENT имя-элемента (потомок1)>
Элементы с анализируемыми символьными
данными
<!ELEMENT имя-элемента (#PCDATA)>
7. 7
Определение элементов
Элементы с любым контентом
<!ELEMENT имя-элемента ANY>
Пустые элементы
<!ELEMENT имя-элемента EMPTY>
Декларация единичного элемента
<!ELEMENT имя-элемента (имя-потомка)>
8. 8
Определение элементов
Декларация минимум одного элемента
<!ELEMENT имя-элемента (имя-потомка+)>
Декларирование от нуля и больше элементов <!
ELEMENT имя-элемента (имя-потомка*)>
Декларирование от нуля до одного элемента
<!ELEMENT имя-элемента (имя-потомка?)>
9. 9
Определение элементов
Декларирование альтернативных элементов
<!ELEMENT note (to,from,header,(message|body))>
Декларирование от нуля и больше элементов <!
ELEMENT имя-элемента (имя-потомка*)>
Декларирование от нуля до одного элемента
<!ELEMENT имя-элемента (имя-потомка?)>
10. 10
Определение атрибутов элементов XML
DTD
Декларация атрибутов
<!ATTLIST имя-элемента имя-атрибута тип-атрибута
значение-атрибута>
Значение атрибута по умолчанию
<!ELEMENT square EMPTY> <!ATTLIST square width
CDATA "0">
>
11. 11
Тип Описание
CDATA Значение — символьные данные
(en1|en2|..) Значение должно быть из перечисленного
списка
ID Значение — уникальный идентификатор
IDREF Значение — идентификатор другого элемента
IDREFS Значение — список других идентификаторов
NMTOKEN Значение — допустимое XML имя
NMTOKENS Значение — список допустимых XML имен
ENTITY Значение — сущность
ENTITIES Значение — список сущностей
NOTATION Значение — имя нотации
xml: Значение — предопределенное xml значение
12. 12
Параметр "значение-атрибута" может принимать
следующие значение
Значение Описание
value Значение атрибута по умолчанию
#REQUIRED Атрибут обязателен
#IMPLIED Атрибут не обязателен
#FIXED value Атрибут имеет фиксированное значение
13. 13
Определение атрибутов элементов XML
DTD
#REQUIRED
<!ATTLIST имя-элемента имя-атрибута тип-атрибута
#REQUIRED>
#IMPLIED
<!ATTLIST имя-элемента имя-атрибута тип-атрибута
#IMPLIED>
#FIXED
<!ATTLIST имя-элемента имя-атрибута тип-атрибута
#FIXED "значение">
16. 16
XML схемы
XSD – класс, XML – объект класса с различными
данными.
Описание на основе XML
Использование любых типов (string, int,
class)
Пространство имен
19. 19
Элемент schema
XML ссылается на схему XSD, на основе
которой он создан
Описовает для XML возможные элементы,
значения, ограничения, типы данных и д.р.
22. 22
Определение атрибутов элементов XML
схемы
Определение атрибута
Значения по умолчанию и фиксированные
значения
Обязательные и необязательные атрибуты
Ограничения по контенту
28. 28
Как работает обработка в SAX
1. Начало документа
2. Начало элемента (samples)
3. Символы (пропуск)
4. Начало элемента (server)
5. Символы (UNIX)
6. Конец элемента (server)
7. Символы (пропуск)
8. Начало элемента (monitor)
9. Символы (color)
10. Конец элемента (monitor)
11. Символы (пропуск)
12. Конец элемента (samples)
Язык XML предназначен для хранения и передачи данных. HTML же предназначен для отображения данных
Недавно в этом учебнике вы узнали о базовых правилах XML-документов; это все хорошо, но вам нужно определить элементы, которые вы собираетесь использовать для представления данных. Вы узнаете о двух способах сделать это в данном разделе.
Одним методом является использование Document Type Definition или DTD (Определение Типа Документа). DTD определяет элементы, которые могут появляться в XML-документе, порядок, в котором они могут появляться, как они могут быть вложены друг в друга и другие основные детали структуры XML-документа. DTD являются частью исходной спецификации XML и они очень похожи на DTD в SGML.
Другим методом является использование XML Schema (схема XML). Схема может определить все то в структуре документа, что вы можете поместить в DTD, и может также определить типы данных и более сложные правила, чем DTD. W3C разработала спецификацию XML Schema через пару лет после исходной спецификации XML.
Определение типов документа (document type definition - DTD) декларирует допустимые строительные блоки XML документа.
Оно задает структуру документа со списком допустимых элементов и атрибутов.
DTD может декларироваться как в коде самого XML документа, так и во внешнем файле с подключением его к XML документу.
С DTD каждый ваш XML файл может нести описание своего собственного формата.
С DTD различные, не связанные друг с другом, группы людей могут приходить к соглашению о стандартах взаимно обмениваемых данных.
С DTD вы можете быть уверены, что получаемые из внешних источников данные будут корректными.
Также, вы можете использовать DTD, чтобы проводит проверки корректности своих собственных данных.
Если DTD декларируется внутри XML файла, то она должны быть заключена в специальный тег декларации DOCTYPE, который имеет следующий синтаксис:
&lt;!DOCTYPE orders [ ]&gt;
exmpl_01
DTD в приведенном примере интерпретируется следующим образом:
!DOCTYPE note определяет, что корневым элементом документа является note
!ELEMENT note определяет, что элемент note содержит четыре элемента: to, from, heading, body
!ELEMENT to определяет, что элемент to должен быть типа &quot;#PCDATA&quot;
!ELEMENT from определяет, что элемент from должен быть типа &quot;#PCDATA&quot;
!ELEMENT heading определяет, что элемент heading должен быть типа &quot;#PCDATA&quot;
!ELEMENT body определяет, что элемент body должен быть типа &quot;#PCDATA&quot;
----------------------------------------------------------------------------------------------------------------------
PCDATA
PCDATA – Анализируемые символьные данные
PCDATA означает анализируемые символьные данные.
Обычно XML парсеры анализируют и разбирают все текстовые данные в XML документе.
Когда парсится XML элемент, текст между тегами XML также анализируется: &lt;message&gt;Этот текст тоже парсится&lt;/message&gt;
Это делается по той причине, что XML элементы могут содержать другие элементы. Например, в следующем примере элемент &lt;name&gt; содержит еще два элемента (first и last): &lt;name&gt;&lt;first&gt;Bill&lt;/first&gt;&lt;last&gt;Gates&lt;/last&gt;&lt;/name&gt; и парсер разобьет его на подэлементы следующим образом:
&lt;name&gt;
&lt;first&gt;Bill&lt;/first&gt;
&lt;last&gt;Gates&lt;/last&gt;
&lt;/name&gt;
&quot;Анализируемые символьные данные&quot; (PCDATA) это термин, используемый по отношению к текстовым данным, которые подвергаются анализу и разбору XML парсером.
----------------------------------------------------------------------------------------------------------------------
CDATA
CDATA - (Неанализируемые) Символьные данные
CDATA — это текст, который не будет анализироваться парсером. Теги внутри такого текста не будут восприняты, как вложенная разметка, а сущности не будут раскрыты.
Термин CDATA используется по отношению текстовых данных, которые не должны анализироваться и разбираться XML парсером.
Символы вроде &quot;&lt;&quot; и &quot;&&quot; недопустимы внутри XML элементов.
Символ &quot;&lt;&quot; вызовет ошибку, потому что парсер будет интерпретировать его, как начало нового элемента.
Символ &quot;&&quot; вызовет ошибку, потому что парсер будет интерпретировать его, как начало символьной сущности.
Тем не менее, некоторые текстовые данные, например, код JavaScript, могут содержать множество символов &quot;&lt;&quot; и &quot;&&quot;. Чтобы избежать возникновения ошибок парсинга, такие текстовые данные можно определить, как CDATA.
Все что расположено внутри секции CDATA полностью игнорируется парсером.
Секция CDATA начинается с символов &quot;&lt;![CDATA[&quot; и заканчивается &quot;]]&gt;&quot;:
Декларация элементов
Элементы с потомками (последовательности) – (Элементы с одним или более потомком декларируются с именем дочернего элемента в скобках). Когда потомки декларируются в последовательности разделенные запятыми, они должны появляться в том же самом порядке. В полной декларации дочерние элементы также должны быть декларированы. Кроме этого, дочерние элементы также могут иметь потомки. Ниже представлена полная декларация элемента “order“
Элементы с анализируемыми символьными данными - (Элементы, содержащие только анализируемые символьные данные, декларируются при помощи ключевого слова #PCDATA)
Элементы с любым контентом - (Элементы, декларированные с ключевым словом категории ANY, могут содержать любую комбинацию анализируемых данных)
Пустые элементы
Декларация единичного элемента – (Декларируется, что элемент “Brand&quot; должен содержать только один дочерний элемент &quot;BrandName “)
Декларация минимум одного элемента – (Знак + декларирует, что элемент &quot;Article&quot; должен содержать один или более дочерних элементов &quot;ArticleName “)
Декларирование от нуля и больше элементов – (Знак * декларирует, что элемент &quot;Article&quot; может содержать сколько угодно дочерних элементов &quot;ArticleName&quot;, либо не содержать их вообще)
Декларирование от нуля до одного элемента – (Знак ? декларирует, что элемент &quot;Article&quot; может содержать только один дочерний элемент &quot;ArticleName&quot;, либо не содержать его вообще)
Декларирование альтернативных элементов– (Декларируется, что элемент &quot;Article&quot; должен содержать элементы &quot;ArticleName&quot;, &quot;ArticleId&quot; и либо элемент &quot;ArticleGuid&quot;, либо элемент “Article1CGuid&quot;.)
Декларирование смешанного контента – (Декларируется, что элемент &quot;Article&quot; может содержать сколько угодно анализируемых символьных данных, элементов &quot;ArticleName&quot; или &quot;ArticleId&quot;, либо не содержать их вообще.)
Параметр &quot;значение-атрибута&quot; может принимать следующие значение
Value Значение атрибута по умолчанию – (В приведенном примере элемент &quot;order&quot; декларируется, как пустой элемент с атрибутом &quot;Id&quot;, который имеет тип CDATA. Если атрибут &quot;Id&quot; не задан, то он будет иметь значение по умолчанию 0.)
#REQUIRED Атрибут обязателен – (Используйте ключевое слово #REQUIRED, если у вас нет вариантов по значению по умолчанию, но вам все же нужно, чтобы атрибут обязательно присутствовал.)
#IMPLIED Атрибут не обязателен – (Ключевое слово #IMPLIED используется, если нет необходимости в обязательном использовании атрибута, и нет вариантов по значению по умолчанию.)
#FIXED value Атрибут имеет фиксированное значение – (Ключевое слово #FIXED используется, когда необходимо, чтобы у атрибута было некое фиксированное значение, которое автор XML файла не может изменять. Если автор XML файла задаст другое значение такого атрибута, то парсер вернет ошибку.)
Если DTD декларируется во внешнем файле, то подключение осуществляется следующим образом:
&lt;!DOCTYPE корневой-элемент SYSTEM &quot;имя файла&quot;&gt;
Ниже приводится тот же XML документ, что и ранее, но с внешней декларацией DTD:
exmpl_02
А вот что содержится в файле &quot;note.dtd&quot;, который декларирует DTD:
Теперь пришло время узнать, что такое XML схемы.
XML схемы, также как DTD, используются для определения допустимых элементов XML документа. Думается, что очень скоро XML схемы будут использоваться в большинстве веб-приложениях вместо DTD, так как XML схемы это основанная на XML альтернатива DTD.
В отличие от DTD, XML схемы поддерживают типы данных и пространства имен.
XML схема описывает структуру XML документа.
Язык XML схем также называют Определение схемы XML или XSD (от анг. XML Schema Definition).
exmpl_03
------------------------------------------------------------------------------
XML схема — это основанная на XML альтернатива DTD.
XML схема описывает структуру XML документа.
Подобно DTD, XML схемы предназначены для определения допустимых строительных блоков XML документа.
XML схема:
определяет элементы, которые могут появляться в XML документе
определяет атрибуты, которые могут появляться в XML документе
определяет, какие элементы являются дочерними
определяет порядок дочерних элементов
определяет количество дочерних элементов
определяет, пустой ли элемент или может содержать текст
определяет типы данных элементов и атрибутов
определяет фиксированные значения и значения по умолчанию элементов и атрибутов
XML схема — преемник DTD
Думается, что очень скоро XML схемы будут использоваться в большинстве веб-приложениях, как замена DTD. И вот некоторые причины этого:
XML схемы легко расширяются
XML схемы - более мощный инструмент, чем DTD
XML схемы пишутся на XML
XML схемы поддерживают типы данных
XML схемы поддерживают пространства имен
XML схемы — это более мощный инструмент определения типов документов, чем DTD.
XML схемы поддерживают типы данных
Один из самых больших плюсов XML схем это поддержка типов данных.
Поддержка типов данных позволяет:
описывать допустимый контент документа
проверять корректность данных
работать с данными из базы данных
определять аспекты данных (ограничения по данным)
определять модели данных (форматы данных)
конвертировать данные между различными типами данных
XML схемы используют синтаксис XML
Еще одним значительным плюсом XML схем является то, что схемы пишутся на XML.
То, что XML схемы пишутся на XML, дает следующие преимущества:
не нужно изучать новый язык программирования
для редактирования схем можно использовать привычный XML редактор
для разбора файлов схем можно использовать тот же XML парсер
можно манипулировать XML схемами при помощи XML DOM
можно трансформировать XML схемы при помощи XSLT
XML схемы обеспечивают безопасную передачу данных
При посылке данных от отправителя к получателю крайне важно, чтобы оба участника имели одинаковые &quot;ожидания&quot; по поводу контента.
При помощи XML схем отправитель может описать данные таким образом, что получатель без труда их поймет.
Например, запись даты: &quot;03-11-2004&quot; в одних странах будет понята, как 3 Ноября, а в других, как 11 Марта.
&lt;date type=&quot;date&quot;&gt;2004-03-11&lt;/date&gt;
XML документ может иметь либо подключение к DTD, либо к XML схеме.
exmpl_04
Элемент &lt;schema&gt; - это корневой элемент каждой XML схемы:
&lt;?xml version=«1.0&quot;?&gt;
&lt;xs:schema&gt; ... &lt;/xs:schema&gt;
Элемент &lt;schema&gt; может содержать некоторые атрибуты. Часто декларация схемы имеет, например, такой вид:
exmpl_05
Фрагмент xmlns:xs=&quot;http://www.w3.org/2001/XMLSchema&quot; указывает на то, что используемые в схеме элементы и типы данных относятся к пространству имен &quot;http://www.w3.org/2001/XMLSchema&quot;. Также здесь указывается, что элементы и типы данных, относящиеся к пространству имен &quot;http://www.w3.org/2001/XMLSchema&quot;, должны иметь префикс xs:
Фрагмент targetNamespace=&quot;http://msiter.ru&quot; указывает на то, что определяемые этой схемой элементы (note, to, from, heading, body) относятся к пространству имен &quot;http://msiter.ru&quot;.
Фрагмент xmlns=&quot;http://msiter.ru&quot; указывает на то, что пространством имен по умолчанию является &quot;http://msiter.ru&quot;.
Фрагмент elementFormDefault=&quot;qualified&quot; указывает на то, что любой элемент, используемый в XML документе, который был декларирован в этой схеме, должен быть уточнен по пространству имен.
Следующий XML документ имеет подключение к XML схеме:
exmpl_06
Здесь фрагмент xmlns=&quot;http://msiter.ru&quot; определяет декларацию пространства имен по умолчанию. Эта декларация говорит валидатору схем, что все элементы, использованные в данном XML документе, декларированы в пространстве имен &quot;http://msiter.ru&quot;.
Благодаря тому, что в фрагменте xmlns:xsi=&quot;http://www.w3.org/2001/XMLSchema-instance&quot; мы сделали доступным пространство имен образцов XML схемы, мы можем использовать атрибут schemaLocation.
У этого атрибута есть два значения, разделенных пробелом.
Первое значение — используемое пространство имен.
Второе значение — расположение XML схемы, которая используется в этом пространстве имен. Что мы и определяем в рагменте xsi:schemaLocation=&quot;http://msiter.ru note.xsd&quot;.
Простой элемент — это элемент XML, который содержит только текст. Простой элемент не может содержать другие элементы или атрибуты.
Тем не менее, ограничение &quot;только текст&quot; достаточно обманчиво. Текст может быть самых разных типов. Это может быть одним из типов, включенных в определение XML схем (boolean, string, date и т.д.), либо это может быть пользовательский тип, определенный вами.
Также, вы сами можете добавить ограничения (аспекты) по типу данных, чтобы лимитировать контент, либо вы можете указать требование, чтобы данные соответствовали определенной модели.
Определение простого элемента
Чтобы определить простой элемент, используется следующий синтаксис: &lt;xs:element name=&quot;xxx&quot; type=&quot;yyy&quot;/&gt;
где xxx — имя элемента, а yyy — тип данных элемента.
XML схемы имеют множество встроенных типов данных. Наиболее часто используемыми являются следующие типы:
xs:string
xs:decimal
xs:integer
xs:boolean
xs:date
xs:time
Значения по умолчанию и фиксированные значения
Простые элементы могут иметь значения по умолчанию ИЛИ фиксированные значения.
Значение по умолчанию присваивается элементу автоматически, если не определено никакого другого значения.
Открыть - exmpl_08
В следующем примере &quot;red&quot; - значение по умолчанию:
&lt;xs:element name=&quot;color&quot; type=&quot;xs:string&quot; default=&quot;red&quot;/&gt;
Фиксированное значение также присваивается элементу автоматически, но при этом вы не можете определить никакого другого значения.
В следующем примере &quot;red&quot; — фиксированное значение:
&lt;xs:element name=&quot;color&quot; type=&quot;xs:string&quot; fixed=&quot;red&quot;/&gt;
Все атрибуты декларируются, как простые типы.
Простые элементы не могут иметь атрибуты. Если у элемента есть атрибуты, то он относится к комплексным или составным типам. Но сам по себе атрибут всегда декларируется, как простой тип.
exmpl_09
Определение атрибута
Атрибут декларируется следующим образом:
&lt;xs:attribute name=&quot;xxx&quot; type=&quot;yyy&quot;/&gt;
где xxx — имя атрибута, а yyy — тип данных атрибута.
XML схемы имеют множество встроенных типов данных. Наиболее часто используемыми являются следующие типы:
xs:string
xs:decimal
xs:integer
xs:boolean
xs:date
xs:time
Значения по умолчанию и фиксированные значения
Атрибуты могут иметь значения по умолчанию ИЛИ фиксированные значения.
Значение по умолчанию присваивается атрибуту автоматически, если не определено никакого другого значения.
В следующем примере &quot;EN&quot; — значение по умолчанию:
&lt;xs:attribute name=&quot;lang&quot; type=&quot;xs:string&quot; default=&quot;EN&quot;/&gt;
Фиксированное значение также присваивается атрибуту автоматически, но при этом вы не можете определить никакого другого значения.
В следующем примере &quot;EN&quot; — фиксированное значение:
&lt;xs:attribute name=&quot;lang&quot; type=&quot;xs:string&quot; fixed=&quot;EN&quot;/&gt;
Обязательные и необязательные атрибуты
По умолчанию атрибуты являются необязательными для использования.
Чтобы декларировать обязательный атрибут, следует воспользоваться атрибутом &quot;use&quot;:
&lt;xs:attribute name=&quot;lang&quot; type=&quot;xs:string&quot; use=&quot;required&quot;/&gt;
Ограничения по контенту
Если XML элемент или атрибут имеет определение типа данных, то это накладывает ограничение по контенту этого элемента или атрибута.
Если XML элемент имеет тип &quot;xs:date&quot; и содержит строку, например, &quot;Hello World&quot;, то этот элемент не пройдет валидацию или проверку на корректность данных.
При помощи XML схем вы также можете добавлять свои собственные ограничения для своих XML элементов и атрибутов. Эти ограничения еще называют аспектами или фасетами.
Если вы имеется отношение к созданию сайтов, вы наверняка слышали об XML, даже если ещё не использовали его в работе. В таком случае, настало время познакомиться, ведь пережив настоящий бум, за последний десяток лет этот новый формат вырос из новаторского проекта в настоящий промышленный стандарт, и чуть ли не ежедневно появляются сообщения о примерах его успешного использования.
Но универсальность текстового формата XML оборачивается вполне очевидным неудобством - перед извлечением данных из документа надо как следует помучиться с синтаксическим анализом текста и определением его структуры. Реализация всех необходимых процедур вручную - весьма нетривиальное занятие, и потребует немалых усилий. Одним из стандартных механизмов, позволяющих упростить жизнь разработчиков, и являются парсеры.
Что же это такое? XML-парсер - это программа, предназначенная для анализа содержимого текстового документа, который соответствует спецификации XML. Ей достается вся &quot;чёрная&quot; работа: получение общих сведений о документе, анализ текста, поиск в нем служебных конструкций (элементов, атрибутов, сущностей и т.п.), проверка на соблюдение синтаксических правил, а также предоставление интерфейса для доступа к документу. В результате аккуратно извлеченные данные, будут переданы пользовательскому приложению, которое может вообще ничего не знать о том, что такое XML.
Парсер может быть выполнен в виде отдельного программного модуля или ActiveX-компонента, может подключаться к приложению через специальные библиотеки классов на этапе компиляции или выполнения. Парсеры делятся на верифицирующие (validating) и неверифицирующие (non-validating). Первые могут проверять структуру документа на основе DTD или схем данных, вторые же об этом не заботятся - и потому имеют, как правило, меньший размер. Многие из современных парсеров &quot;нагружены&quot; многочисленными дополнительными возможностями (расширенная обработка ошибок, добавление и редактирование данных), что делает их более удобными в работе, хотя и повышает размер программ.
Наиболее распространенным и известным является парсер Expat, написанный Джеймсом Кларком - одним из создателей спецификации XML.
Другой распространенный парсер - Xerces
В этом разделе рассматривается ряд программных интерфейсов для XML. Эти интерфейсы дают разработчикам целостный интерфейс для работы с XML-документами.
Существует много доступных API; в этом разделе рассматриваются две из них, наиболее популярные и наиболее часто используемые:
Объектная Модель Документа (Document Object Model - DOM)
Простой API для XML (Simple API for XML - SAX
Чтобы обойти проблемы DOM, участники XML-DEV (возглавляемой David Megginson) создали интерфейс SAX. SAX имеет несколько характеристик, направленных на преодоление недостатков DOM:
Парсер SAX посылает в ваш код события. Парсер сообщает вам, когда он находит начало элемента, конец элемента, текст, начало и конец документа и т.д. Вы решаете, какие события важны для вас, вы решаете, какой вид структуры данных вы хотите создать для хранения данных из этих событий. Если вы явным образом не сохраняете данные из этих событий, они теряются.
Парсер SAX не создает никаких объектов вообще, он просто доставляет события в ваше приложение. Если вы хотите создавать объекты на основе этих событий - это ваше дело.
Парсер SAX начинает доставляет вам события сразу же после начала своей работы. Ваш код получить событие, когда парсер найдет начало документа, когда он найдет начало элемента, когда он найдет текст и т.д. Ваше приложение сразу же начнет генерировать результаты и не будет должно ожидать, пока будет разобран весь документ. Даже лучше, если вы ищете только определенные вещи в документе, ваш код может сгенерировать исключение, если он нашел то, что искал. Исключение останавливает парсер SAX, и ваш код может делать то, что ему нужно сделать с найденными данными
Проблемы SAX
Чтобы быть честными, парсеры SAX также имеют проблемы, которые могут вызывать опасения:
События SAX не сохраняют состояния. Когда парсер SAX находит текст в XML-документе, он посылает событие в ваш код. Это событие просто дает вам найденный текст; оно не сообщает вам, какой элемент содержит этот текст. Если вы хотите знать это, вы должны написать код, управляющий состоянием, сами.
События SAX не сохраняются. Если вашему приложению нужна структура данных, которая моделирует XML-документ, вы должны написать этот код сами. Если вам нужно обращаться к данным из события SAX, и вы не сохранили данные в вашем коде, вы должны разобрать документ снова.
SAX не управляется централизованной организацией. Хотя пока это не составило проблем, некоторым разработчикам показалось бы более комфортабельным, если бы SAX управляется организацией, такой как W3C.
SAX анализирует поток XML и проходит через, как по телетайпной ленте. Рассмотрим следующий XML-код:
&lt;?xml version=&quot;1.0&quot;?&gt; &lt;samples&gt; &lt;server&gt;UNIX&lt;/server&gt; &lt;monitor&gt;color&lt;/monitor&gt; &lt;/samples&gt;
Процессор SAX, анализирующий этот код, будет генерировать, как правило, следующие события:
SAX API дает возможность разработчику выловить эти события и работать по ним.
Обработка в SAX включает в себя следующие шаги:
Создание обработчика событий.
Создание парсера SAX.
Назначение обработчика событий для парсера.
Разбор документа с посылкой каждого события в обработчик.
За и против событийно-базированной обработки
Преимущества этого вида обработки очень похожи на преимущества потоковых носителей. Анализ может начинаться немедленно, а не ожидать всех данных для обработки. Также поскольку работает с данными по мере их поступления, не требуется сохранять их в памяти. Это огромное преимущество, когда поступают большие документы. Фактически, приложение даже не должно разбирать весь документ; оно может остановиться, когда будут удовлетворены некоторые критерии. В общем случае SAX также значительно быстрее, чем его альтернатива, DOM.
С другой стороны, поскольку приложение не сохраняет каким-либо образом данные, невозможно при помощи SAX делать в них изменения или возвращаться назад по потоку данных.
Объектная Модель Документа, обычно называемая DOM, определяет набор интерфейсов для разобранной версии XML-документа. Парсер читает весь документ и строит дерево в памяти, так что ваш код может использовать интерфейсы DOM для манипулирования деревом. Вы можете двигаться по дереву, чтобы увидеть, что содержал исходный документ, вы можете удалять части дерева, вы можете переупорядочить дерево, добавлять новые ветви и т.д. DOM была создана W3C, и это - Официальная Рекомендация консорциума.
Проблемы DOM
DOM обеспечивает богатый набор функций, которые вы можете использовать для интерпретации XML-документа и манипулирования им, но за эти функции надо платить.
Когда была разработана исходная DOM для XML-документов, многие люди в списке рассылки XML-DEV выразили беспокойство по поводу ее:
DOM строит в памяти дерево всего документа. Если документ очень большой, это требует значительного объема памяти.
DOM создает объекты, которые представляют все, что есть в исходном документе, включая элементы, текст, атрибуты и пропуски. Если вам нужно иметь дело только с небольшой порцией исходного документа, то крайне расточительно создавать все эти объекты, которые никогда не будут использованы.
Парсер DOM должен прочитать весь документ прежде, чем ваш код получит управление. Для очень больших документов это может привести к значительной задержке.
Это только спорные вопросы, возникшие при проектировании DOM; несмотря на это, API DOM является очень удобным способом для разбора XML-документов.
Основой Расширяемого Языка Разметки, Extensible Markup Language или XML является DOM. XML-документы содержат иерархию информационных единиц, называемых узлами; DOM является способом описания этих узлов и отношений между ними.
Вдобавок к ее роли концептуального описания XML-данных, DOM является серией Рекомендаций, вырабатываемых Консорциумом World Wide Web (W3C). DOM начиналась как способ для Web-браузеров для идентификации и манипулирования элементами на странице - функциональности, которая еще предшествовала вовлечению в нее W3C и известна, как &quot;DOM, Уровень 0&quot;.
DOM как структура
Прежде, чем начинать работу с DOM, стоит получить представление о том, что она на самом деле представляет. Объект DOM Document является коллекцией узлов или порций информации, организованных в иерархию. Эта иерархия позволяет разработчику двигаться по дереву в поисках нужной информации. Анализ структуры обычно требует, чтобы был загружен полный документ, и иерархия была построена до начала работы. Поскольку DOM основывается на иерархии информации, про нее говорят, что она древовидно-базированная или объектно-базированная.
Для исключительно больших документов разбор и загрузка полного документа может быть медленной и ресурсоемкой, так что для работы с такими данными могут оказаться лучшими другие средства. Событийно-базированные модели, такие, как Simple API for XML (SAX), работают на потоке данных, обрабатывая его по мере поступления. (SAX является темой другого учебника и других статей в XML-зоне developerWorks. Дополнительную информацию см. в Ресурсы.)
Событийно-базированный API обходит необходимость построения дерева в памяти, но фактически не позволяет разработчику изменять данные в исходном документе.
