Дилемма 3.Нужна ли схема?
На самом деле существует, по крайней мере, три способа определения схемы документа XML, в том числе DTD, Documet Type Definition и XMLShcema. Последняя является новейшей разработкой, находящейся на стадии стандартизации, и всем разработчикам рекомендовано придерживаться именно этого синтаксиса. Учебник для начинающих можно найти по адресу: www.w3.org/TR/xmlschema-0/.
Самое главное — это то, как вы собираетесь в будущем использовать свои документы и схемы. Возможны три варианта:
1. Структура документа жестко зафиксирована в программе. Например, если вы разбираете XML, полученный как результат запроса к известной базе данных, то ваша программа может выбирать совершенно определенные элементы.
2. Вторая версия происходящего — ссылка на схему приводится в самом документе — например так, как HTML-документ ссылается на CSS. Выглядит это следующим образом:
| <article xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="article.xsd"> |
В таком случае вы можете верифицировать документ относительно такой схемы стандартными средствами SAX и DOM. Другое дело: что делать, если документ не проходит валидацию? Но, тем не менее, это уже что-то.
3. Вариант третий — вы получаете документы из внешнего источника, ничего не зная об их схеме. Простой пример — HTML-документ произвольной структуры. В таком случае вы можете только проверить, удовлетворяет ли документ условиям валидности.
Фактически по отношению к схеме возможна только одна операция — верификация документа с простым вопросом: «удовлетворяет ли документ схеме?». Кроме того, приложение на основании схемы может распределять память — то есть создавать иерархию объектов для документа определенного типа. Учитывая тот факт, что схема является моделью данных, можно рекомендовать всегда строить схему для случаев, когда XML-данные первичны, и опираться на UML-представление структуры БД, когда XML-данные экспортируются из БД.
Дилемма 4.
DOM или SAX?
И тот, и другой метод позволяют разбирать и работать с одними и теми же XML-документами — но на разном уровне.
DOM — это общий способ представления иерархических документов, рекомендация W3C к представлению и методу доступа (фактически сокращение Document Object Model совершенно не ссылается на XML). Архитектурно DOM основан на узловом представлении, то есть объектами представляются элементы, а не связи между ними. В основе иерархии стоит класс Узла — в его функции входит двусторонняя связь по вертикали (с родительским узлом) и по горизонтали (с сестринскими узлами). У каждого узла не более одного сестринского элемента, предшествующего и следующего за ним.
От узла происходят Элементы — это такие узлы, которые дополнительно содержат два списка: список дочерних элементов и список атрибутов. Атрибуты — это пары ключ-значение. Имена ключей должны быть уникальными, но их порядок не имеет значения.
Рисунок: Иллюстрация иерархии объектов DOM. Линии представляют двусторонние связи
Особый случай элемента — Документ, который всегда является корневым элементом. Документ имеет уникальное имя и не имеет родительского элемента. Все остальные узлы имеют родительский документ, причем только один.
От узла происходят также два листовых (не имеющих дочерних) типа узла — Текст и Комментарий. В списке дочерних элементов элемента могут чередоваться узлы других элементов, текста и комментарии в любом порядке.
Помимо классов, над ними определены методы — типично «добавить узел», «удалить узел», «добавить атрибут», «удалить атрибут» и так далее.
Недостаток DOM — достаточно большие накладные расходы на обработку каждого элемента; они могут составлять даже 1000% и более от нетто данных. При обработке больших документов это может стать критическим параметром. Кроме того, некоторые операции с DOM-представлением (такие как поиск) будут связаны со сложным обходом дерева, и в общем случае они медленнее линейного поиска.
Метод доступа через DOM удобен, когда структура документа должна (или может) быть доступна в целом и легко модифицироваться — например так, как это происходит в документе Word или при формировании страницы DHTML.
SAX, Simple API for XML — это де-факто стандартный метод разбора, завязанный конкретно на XML. В основе лежит обработка событий — то есть при открытии и закрытии каждого элемента, получении текста и так далее ваша программа получает управление, сопровождаемое параметрами события. Для своей работы этот метод не требует использования больших хранилищ данных или иерархий объектов в памяти, так что можно обрабатывать очень большие объемы данных на ограниченных ресурсах (как пример практически бесконечного XML-потока представьте датчик сигналов, генерирующий бесконечную последовательность XML-элементов).
Кроме того, SAX-разбор происходит асинхронно, то есть программа не должна ждать завершающего тега для отработки уже полученных. Последнее может пригодиться, например, для отображения записей SQL-запроса еще до того, как все они будут получены. Другое применение — обрыв сеанса, допустим при нахождении одной нужной записи из миллиона.
Недостаток SAX — необходимость хранения состояния в процессе разбора XML-потока, то есть в случае со сложной и/или недетерминированной структурой придется частично реконструировать узловую модель для отслеживания уровней вложения.
SAX и DOM подходы иногда сочетают между собой. Так, веб-браузер отображает элементы в процессе получения по методу SAX, но после получения документа строит его DOM-модель для DHTML-доступа в терминах иерархии объектов.
