Основы XML для начинающих. XML Основы


Язык XML - практическое введение. Часть 2

Детальное описание Databet88 .

XML (Extensible Markup Language) - это новый SGML-производный язык разметки документов, позволяющий структурировать информацию разного типа, используя для этого произвольный набор инструкций. Разработчиков Интернет приложений, пытающихся на практике использовать новую технологию, могут заинтересовать конкретные вопросы, связанные с проблемами создания, обработки XML-документов, их отображения на стороне клиента. В этой статье дается краткое представление о том, что представляет собой и для чего нужен XML-документ и на практических примерах иллюстрируются некоторые простые, но пока, к сожалению, мало описанные механизмы его обработки.

Что такое XML

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

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

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

Как создать XML документ?

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

Важная деловая встреча Надо встретиться с Иваном Ивановичем, предварительно позвонив ему по телефону 123-12-12 ... Позвонить домой 124-13-13

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

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

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

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

Следующей этапом продвижения документа является рабочий вариант спецификации, который составляет и изменяет в дальнейшем специально созданная рабочая группа (Working Group), в состав которой входят представители заинтересовавшихся идеей компаний. Все изменения, вносимые в этот документ обязательно публикуются на сервере консорциума www.w3.org и до тех пор, пока рабочий вариант не станет рекомендацией, он может служить для разработчиков лишь "путеводной звездой", с которой компания может сверять свои планы, но не должна использовать при разработке ПО.

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

XML-генераторы

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

Пусть, например, нашей задачей является создание формата хранения данных регистрации каких-то происходящих в системе событий (log-файла). В простейшем случае можно ограничиться фиксированием успешных и ошибочных запросов к нашим ресурсам - в таком документе должна присутствовать информация о времени произошедшего события, его результате (удача/ошибка), IP адресе источника запроса, URI ресурса и коде результата.

Наш XML документ может выглядеть следующим образом:

195.151.62.18 GET /misc/ 200 195.209.248.12 GET /soft.htm 200

Структура документа довольно проста - корневым в данном случае является элемент log, каждое произошедшее событие фиксируется в элементе event и описывается при помощи его атрибутов(date - время и result - тип события) и внутренних элементов (method - метод доступа, ip-from - адрес источника, url-to - запрашиваемый ресурс, response - код ответа). Генерацией этого документа может заниматься, например, модуль аутентификации запросов в систему, а использованием - программа обработки регистрационных данных (log viewer).

Что такое DTD?

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

Сохраните этот файл под именем log.dtd и включите в XML-документ новую строчку:

Теперь верифицирующий XML-анализатор при обработке документа будет сверять порядок определения элементов и их атрибутов с тем, как это указано у нас в DTD-нотациях и в случае нарушения внутренней структуры (которая определяет "семантику" документа) выдавать сообщение об ошибке.

Что такое Namespaces?

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

Чтобы исправить эту ситуацию, мы должны определить уникальные названия элементов и их атрибутов, "дописывая" к их обычным именам некоторый универсальный неповторяющийся префикс. Для этого применяется механизм Namespaces (спецификация Namespaces была официально утверждена W3C в январе 1999 года и сегодня является частью стандарта XML). Согласно этой спецификации, для определения "области действия" тэга (на самом деле этот термин, широко используемый в обычных языках программирования, неприменим в XML, потому что как такового множества, на котором могла бы быть построена "область", внутри структурированного XML документа нет) необходимо определить уникальный атрибут, описывающий название элемента, по которому анализатор документа сможет определить, к какой группе имен оно относится (Namespace идентификаторы могут применяться для описания уникальных названий как элементов, так и их атрибутов). В нашем последнем примере это может быть сделано так:

195.151.62.18

GET

/misc/

200

195.209.248.12

GET

/soft.htm

200

Уникальность атрибуту имени обеспечивает использование в качестве его значения некоторых универсальных идентификаторов ресурсов (например, URI или ISBN) .

Полную информацию по использованию Namespace вы можете найти в официальной спецификации этого стандарта. В дальнейшем, для упрощения примеров, мы будем Namespace - описания пропускать.

Инструментарий

Обработка XML-документов

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

В августе 1997 RFC 2376 были утверждены MIME типы для XML-ресурсов: text/xml и application/xml. Поэтому XML документы могут передаваться по HTTP и отображаться программой просмотра также, как и обычные HTML- страницы. Для этого нужно немного изменить конфигурацию Web-сервера (в Apache - добавить в файл mime.types строчку "text/xml xml ddt"), а на стороне клиента иметь броузер, поддерживающий стилевые таблицы или JavaScript. Сегодня такими броузерами являются Microsoft Internet Explorer 5, первый броузер, поддерживающий спецификацию XML 1.0 и стилевые таблицы XSL; броузер Amaya, предлагаемый консорциумом специально для тестовых целей (http://www.w3.org/Amaya/User/BinDist.html) и поддерживающий практически все разрабатываемые стандарты W3C. Поддержка XML также планируется в будущих версиях Netscape Navigator.

Объектная модель документа DOM

Одним из самых мощных интерфейсов доступа к содержимому XML документов является Document Object Model - DOM.

Объектная модель XML документов является представлением его внутренней структуры в виде совокупности определенных объектов. Для удобства эти объекты организуются в некоторую древообразную структуру данных - каждый элемент документа может быть отнесен к отдельной ветви, а все его содержимое, в виде набора вложенных элементов, комментариев, секций CDATA и т.д. представляется в этой структуре поддеревьями. Т.к. в любом правильно составленном XML-документе обязательно определен главный элемент, то все содержимое можно рассматривать как поддеревья этого основного элемента, называемого в таком случае корнем дерева документа. Для следующего фрагмента XML документа:

text text

дерево элементов выглядит так:

Рис.1 Дерево элементов

Объектное представление структуры документа не является чем-то новым для разработчиков. Для доступа к содержимому HTML страницы в сценариях давно используется объектно-ориентированный подход, - доступные для Java Script или VBScript элементы HTML документа могли создаваться, модифицироваться и просматриваться при помощи соответствующих объектов. Но их список и набор методов постоянно изменяется и зависит от типа броузера и версии языка. Для того, чтобы обеспечить независимый от конкретного языка программирования и типа документа интерфейс доступа к содержимому структурированного документа в рамках W3 консорциума была разработана и официально утверждена спецификация объектной модели DOM Level 1.

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

Для описания интерфейсов доступа к содержимому XML документов в спецификации DOM применяется платформонезависимый язык IDL и для использования их необходимо "перевести" на какой-то конкретный язык программирования. Однако этим занимаются создатели самих анализаторов, нам можно ничего не знать о способе реализации интерфейсов - с точки зрения разработчиков прикладных программ DOM выглядит как набор объектов с определенными методами и свойствами. В следующем разделе мы вкратце рассмотрим объектную модель Microsoft Internet Explorer 5, доступную из Java Script и VBScript сценариев.

XML - очень популярный и гибкий формат в наше время. Каждый программист должен понимать его, это просто must have. Многие технологии завязаны сегодня активно его используют, при чем современные в их числе.

Вступление

Здравствуйте, дорогие читатели моей статьи. Сразу хочу сказать, что это только первая статья в моём цикле из трёх статей. Основная цель всего цикла – посвятить каждого читателя в XML и дать, если не полное разъяснение и понимание, то, хотя бы, хороший такой толчок к нему, объяснив основные моменты и вещи. Весь цикл будет для одной номинации – «Внимание к деталям» , а разделение на 3 статьи сделано для того, чтобы вмещаться в лимит символов в постах и разделить большое количество материала на более маленькие порции для большего понимания. Первая статья будет посвящена самому XML и что это такое, а так же одному из способов составления схемы для XML файлов – DTD. Для начала, хотелось бы высказать небольшое предисловие для тех, кто вообще еще не знаком с XML: не нужно пугаться. XML не очень сложный и с ним нужно разобраться любому программисту, так как это очень гибкий, эффективный и популярный формат файлов на сегодняшний день для хранения разнообразной информации, какой вы только захотите. XML используется в Ant, Maven, Spring. Любому программисту нужно знание XML. Теперь, когда вы собрались силами и мотивацией, давайте приступать к изучению. Весь материал я буду пытаться выложить максимально просто, собрав только самое важное и не вдаваться в дебри.

XML

Для более ясного объяснения, правильней будет визуализировать XML примером. < ? xml version= "1.0" encoding= "UTF-8" ? > < company> < name> IT- Heaven< / name> < offices> < office floor= "1" room= "1" > < employees> < employee> < name> Maksim< / name> < job> Middle Software Developer< / job> < / employee> < employee> < name> Ivan< / name> < job> Junior Software Developer< / job> < / employee> < employee> < name> Franklin< / name> < job> Junior Software Developer< / job> < / employee> < / employees> < / office> < office floor= "1" room= "2" > < employees> < employee> < name> Herald< / name> < job> Middle Software Developer< / job> < / employee> < employee> < name> Adam< / name> < job> Middle Software Developer< / job> < / employee> < employee> < name> Leroy< / name> < job> Junior Software Developer< / job> < / employee> < / employees> < / office> < / offices> < / company> HTML и XML похожи синтаксисом, так как у них общий родитель – SGML. Однако, в HTML есть только фиксированные теги конкретного стандарта, в то время, как в XML вы можете создавать свои собственные теги, атрибуты и, в целом, делать все, что захотите, чтобы хранить данные так, как вам будет удобно. По сути, XML файлы может прочитать любой человек, знающий английский язык. Изобразить данный пример можно с помощью дерева. Корень дерева – Company. Он же – корневой (рут) элемент, от которого идут все остальные элементы. В каждом XML файле может быть только один рут элемент. Он должен объявляться после декларации xml файла (первая строчка в примере) и вмещать в себе все другие элементы. Немного о декларации: она обязательная и нужна для идентификации документа как XML. У неё есть три псевдо-атрибуты (специальные предопределенные атрибуты): version (по стандарту 1.0), encoding (кодировка) и standalone (автономность: если yes и к документу подключаются внешние схемы, то будет ошибка, по умолчанию - no). Элементы – это сущности, которые хранят данные с помощью других элементов и атрибутов. Атрибуты – это дополнительная информация об элементе, которая указывается при добавлении элемента. Если перевести объяснение на ООП-поле, то можно привести такой пример: у нас есть машина, у каждой машины есть характеристики (цвет, вместимость, марка и другое) – это атрибуты, и есть сущности, которые внутри машины: двери, окна, двигатель, руль – это другие элементы. Хранить свойства можно как и отдельными элементами, так и атрибутами в зависимости от вашего желания. Как никак, XML – крайне гибкий формат хранения информации про что-либо. После объяснений, нам достаточно разобрать пример выше, чтобы все встало на свои места. В примере мы описали простую структуру компании: есть компания, у которой есть имя и офисы, а в офисах есть сотрудники. Элементы Employees и Offices – элементы-обертки – они служат для того, чтобы собрать в себе элементы одного вида, по сути, соединив их в одно множество для удобства их обработки. Отдельного внимания заслуживают floor и room. Это – атрибуты офиса (этаж и номер), другими словами – его свойства. Если бы у нас был элемент «картинка», то можно было бы передавать её размеры. Вы можете заметить, что у компании нет атрибута name, но есть элемент name. Просто вы можете описывать структуры так, как захотите. Никто не обязывает вас все свойства элементов записывать только в атрибуты, вы можете использовать и просто элементы и записывать внутри них какие-то данные. Например, мы можем записывать имя и должность наших работников, как атрибуты: < ? xml version= "1.0" encoding= "UTF-8" ? > < company> < name> IT- Heaven< / name> < offices> < office floor= "1" room= "1" > < employees> < employee name= "Maksim" job= "Middle Software Developer" > < / employee> < employee name= "Ivan" job= "Junior Software Developer" > < / employee> < employee name= "Franklin" job= "Junior Software Developer" > < / employee> < / employees> < / office> < office floor= "1" room= "2" > < employees> < employee name= "Herald" job= "Middle Software Developer" > < / employee> < employee name= "Adam" job= "Middle Software Developer" > < / employee> < employee name= "Leroy" job= "Junior Software Developer" > < / employee> < / employees> < / office> < / offices> < / company> Как вы видите, теперь имя и должность каждого работника – это его атрибуты. И можно заметить, что внутри сущности (тега) employee ничего нет, все элементы employee – пустые. Тогда можно сделать employee пустым элементом – закрыть его сразу после объявления атрибутов. Это делается довольно просто, достаточно просто поставить слэш: < ? xml version= "1.0" encoding= "UTF-8" ? > < company> < name> IT- Heaven< / name> < offices> < office floor= "1" room= "1" > < employees> < employee name= "Maksim" job= "Middle Software Developer" / > < employee name= "Ivan" job= "Junior Software Developer" / > < employee name= "Franklin" job= "Junior Software Developer" / > < / employees> < / office> < office floor= "1" room= "2" > < employees> < employee name= "Herald" job= "Middle Software Developer" / > < employee name= "Adam" job= "Middle Software Developer" / > < employee name= "Leroy" job= "Junior Software Developer" / > < / employees> < / office> < / offices> < / company> Как вы можете заметить, закрыв пустые элементы мы сохранили всю целостность информации и намного сократили запись, сделав информацию более сжатой и читабельной. Для того, чтобы добавить комментарий (текст, который будет пропускаться при парсинге файла) в XML, есть следующий синтаксис: < ! -- Иван недавно уволился, только неделю отработать должен. Не забудьте потом удалить его из списка. -- > И последняя конструкция – это CDATA , означает «символьные данные». Благодаря данной конструкции, можно записывать текст, который не будет интерпретироваться как разметка XML. Это полезно, если внутри XML файла у вас есть сущность, которая хранит в информации XML разметку. Пример: < ? xml version= "1.0" encoding= "UTF-8" ? > < bean> < information> < ! [ CDATA[ < name> Ivan< / name> < age> 26 < / age> ] ] > < / information> < / bean> Особенность XML в том, что вы можете расширять его так, как захотите: использовать свои элементы, свои атрибуты и структурировать его по своему желанию. Вы можете использовать для хранения данных как атрибуты, так и элементы (как это было показано в примере ранее). Однако нужно понимать, что придумывать свои элементы и атрибуты на ходу и как вы захотите вы можете, но что, если вы будете работать на проекте, где другой программист захочет перенести элемент name в атрибуты, а у вас вся логика программы написана так, чтобы name был элементом? Как же создать свои собственные правила того, какие элементы должны быть, какие атрибуты у них есть и другие вещи, чтобы можно было проводить валидацию XML файлов и быть уверенным, что правила станут стандартными в вашем проекте и никто их нарушать не будет? Для того, чтобы написать все правила вашей собственной XML разметки, есть специальные средства. Самые известные: DTD и XML Schema. В этой статье будет только про первое.

DTD

DTD создан для того, чтобы описывать типы документов. DTD уже устаревает и сейчас от него активно отказываются в XML, однако еще много XML файлов используют именно DTD и, в целом, его полезно понимать. DTD – это технология валидации XML-документов . DTD объявляет конкретные правила для типа документа: его элементы, какие элементы могут быть внутри элемента, атрибуты, обязательные они или нет, количество их повторений, а так же сущности (Entity). По аналогии с XML, для более ясного объяснения DTD можно визуализировать примером. < ! -- Объявление возможных элементов -- > < ! ELEMENT employee EMPTY> < ! ELEMENT employees (employee+ ) > < ! ELEMENT office (employees) > < ! ELEMENT offices (office+ ) > < ! ELEMENT name (#PCDATA) > < ! ELEMENT company (name, offices) > < ! -- Добавление атрибутов для элементов employee и office -- > < ! ATTLIST employee name CDATA #REQUIRED job CDATA #REQUIRED > < ! ATTLIST office floor CDATA #REQUIRED room CDATA #REQUIRED > < ! -- Добавление сущностей -- > < ! ENTITY M "Maksim" > < ! ENTITY I "Ivan" > < ! ENTITY F "Franklin" > Вот такой вот простой пример у нас есть. В данном примере, мы объявили всю нашу иерархию из XML примера: работник, работники, офис, офисы, имя, компания. Для создания DTD файлов служат 3 основные конструкции, чтобы описывать любые XML файлы: ELEMENT (для описания элементов), ATTLIST (для описания атрибутов для элементов) и ENTITY (для подстановки текста сокращенными формами). ELEMENT Служит для описания элемента. Элементы, которые можно использовать внутри описанного элемента, перечисляются в скобках в виде списка. Можно использовать квантификаторы для указания количества (они аналогичны с квантификаторами из регулярных выражений): + значит 1+ * значит 0+ ? значит 0 ИЛИ 1 Если квантификаторов не было добавлено, то считается, что должен быть только 1 элемент. Если бы нам нужен был один из группы элементов, можно было бы написать так: < ! ELEMENT company ((name | offices) ) > Тогда выбирался бы один из элементов: name или offices, но если бы внутри company было сразу два их, то валидация бы не проходила. Так же можно заметить, что в employee есть слово EMPTY – это значит, что элемент должен быть пустым. Есть еще ANY – любые элементы. #PCDATA – текстовые данные. ATTLIST Служит для добавления атрибутов к элементам. После ATTLIST следует название нужного элемента, а после словарь вида «название атрибута – тип атрибута», а в конце можно добавить #IMPLIED (не обязателен) или #REQUIRED (обязателен). CDATA – текстовые данные. Есть и другие типы, однако все они строчные. ENTITY ENTITY служит для объявления сокращений и текста, который будет на них подстваляться. По сути, мы просто сможем использовать в XML вместо полного текста просто название сущности со знаком & перед и; после. Например: чтобы отличать разметку в HTML и просто символы, левую угловую скобочку часто экранируют с помощью lt; , только нужно еще выставить & перед lt. Тогда мы будем использовать не разметку, а просто символ < . Как вы можете видеть, все довольно просто: объявляете элементы, объясняете, какие элементы объявленные элементы способны содержать, добавление атрибутов этим элементам и, по желанию, можете добавить сущности, чтобы сокращать какие-то записи. И тут вы должны были бы спросить: а как использовать наши правила в нашем XML файле? Ведь мы просто объявили правила, но мы не использовали их в XML. Есть два способа использовать их в XML: 1. Внедрение - написание DTD правил внутри самого XML файла, достаточно просто написать корневой элемент после ключевого слова DOCTYPE и заключить наш DTD файл внутри квадратных скобочек. < ? xml version= "1.0" encoding= "UTF-8" ? > < ! DOCTYPE company [ < ! -- Объявление возможных элементов -- > < ! ELEMENT employee EMPTY> < ! ELEMENT employees (employee+ ) > < ! ELEMENT office (employees) > < ! ELEMENT offices (office+ ) > < ! ELEMENT name (#PCDATA) > < ! ELEMENT company (name, offices) > < ! -- Добавление атрибутов для элементов employee и office -- > < ! ATTLIST employee name CDATA #REQUIRED job CDATA #REQUIRED > < ! ATTLIST office floor CDATA #REQUIRED room CDATA #REQUIRED > < ! -- Добавление сущностей -- > < ! ENTITY M "Maksim" > < ! ENTITY I "Ivan" > < ! ENTITY F "Franklin" > ] > < company> < name> IT- Heaven< / name> < ! -- Иван недавно уволился, только неделю отработать должен. Не забудьте потом удалить его из списка. -- > < offices> < office floor= "1" room= "1" > < employees> < employee name= "&M;" job= "Middle Software Developer" / > < employee name= "&I;" job= "Junior Software Developer" / > < employee name= "&F;" job= "Junior Software Developer" / > < / employees> < / office> < office floor= "1" room= "2" > < employees> < employee name= "Herald" job= "Middle Software Developer" / > < employee name= "Adam" job= "Middle Software Developer" / > < employee name= "Leroy" job= "Junior Software Developer" / > < / employees> < / office> < / offices> < / company> 2. Импорт - мы записываем все наши правила в отдельный DTD файл, после чего в XML файле используем DOCTYPE-конструкцию из первого способа, только вместо квадратных скобочек нужно написать SYSTEM и указать абсолютный или относительный до текущего местоположения файла путь. < ? xml version= "1.0" encoding= "UTF-8" ? > < ! DOCTYPE company SYSTEM "dtd_example1.dtd" > < company> < name> IT- Heaven< / name> < ! -- Иван недавно уволился, только неделю отработать должен. Не забудьте потом удалить его из списка. -- > < offices> < office floor= "1" room= "1" > < employees> < employee name= "&M;" job= "Middle Software Developer" / > < employee name= "&I;" job= "Junior Software Developer" / > < employee name= "&F;" job= "Junior Software Developer" / > < / employees> < / office> < office floor= "1" room= "2" > < employees> < employee name= "Herald" job= "Middle Software Developer" / > < employee name= "Adam" job= "Middle Software Developer" / > < employee name= "Leroy" job= "Junior Software Developer" / > < / employees> < / office> < / offices> < / company> Так же можно использовать ключевое слово PUBLIC вместо SYSTEM, однако оно вряд ли вам пригодится. Если интересно, то почитать про него (и про SYSTEM тоже) можно подробно тут: ссылочка . Теперь мы не можем использовать другие элементы без их объявления в DTD, а весь XML подчиняется нашим правилам. Можете попробовать записать данный код в IntelliJ IDEA в отдельный файл с расширением.xml и попробовать добавить какие-то новые элементы или удалить элемент из нашего DTD и заметите, как IDE будет указывать вам на ошибку. Однако, у DTD есть свои минусы:
  • У него свой собственный синтаксис, отличный от синтаксиса xml.
  • В DTD нет проверки типов данных, а содержать он может только строки.
  • В DTD нет пространства имён.
О проблеме собственного синтаксиса: вы должны разбираться в двух синтаксисах сразу: в XML и в DTD синтаксисе. Они разные и это может заставлять вас путаться. Так же, из-за этого же сложней отслеживать ошибки в огромных XML файлах в соединении с такими же DTD схемами. Если у вас что-то не заработало, приходится проверять огромное количество текста разных синтаксисов. Это как читать одновременно две книжки: на русском и английском. И если знание у одного языка у вас хуже, то понимать текст будет так же сложней. О проблеме проверки типов данных: у атрибутов в DTD действительно есть разные типы, но все они, по сути своей, являются строковыми представлениями чего-либо, списками или ссылками. Однако, вы не можете требовать только числа, и, тем более, позитивные или негативные. А про объектные типы можете вообще забыть. Последняя проблема будет обсуждаться уже в следующей статье, которая будет посвящена пространствам имён и XML схемам, так как обсуждение её тут бессмысленно. Спасибо всем за внимание, я проделал большую работу и продолжаю её проделывать, чтобы вовремя закончить весь цикл статей. По сути, мне осталось разобраться с XML схемами и придумать их объяснение более ясными словами, чтобы закончить 2-ю статью. Её половина уже сделана, так что можете ожидать её в ближайшее время. Последняя статья будет полностью посвящена работе с XML файлами средствами Java. Удачи всем и успехов в программировании:) Следующая статья: 1. Введение

Если кто-либо из вас когда-нибудь пытался изучить XML своими силами, Вы возможно встречались со многими сбивающими с толку понятиями, обрушившимися и на меня в свое время. DTD, XML Schema, пространства имен (namespaces), XPath, XPointers, XSL, XSLT, DOM, SAX, SOAP, Все, я сдаюсь. Добавлю лишь, что большинство из этих материалов основано на реализациях, код которых может содержать ошибки. Наверняка существуют миллионы способов реализации и использования XML, но они все могут быть достаточно сложны. А знаете, XML может быть и очень простым. Если мы забудем про DTD, XML Schemas, пространства имен (namespaces), и т.п.
Стараясь быстрее обучить вас работе с XML, я буду по возможности игнорировать приличную долю информации, которую вы и так сможете прочитать в соответствующей литературе. И первое что я собираюсь проигнорировать, это пространства имен (namespaces) и схемы (schemas). Вам это может показаться странным, так как большинство книг начинаются именно с объяснения этих понятий, но постарайтесь думать об XML как о средстве решить конкретную задачу, как, например, о молотке. Для того чтобы пользоваться молотком, разве обязательно знать, как построить дом? Что если все что мне нужно, это просто вбить гвоздь чтобы повесить на него картину? То же самое и с XML, он может быть и очень сложным, достаточно универсальным для использования в сотнях, если не в тысячах приложений, и очень простым, если не обращать внимания на некоторые вещи. В этой статье, я буду концентрироваться на решении конкретных проблем с помощью XML.
Так в чем же собственно проблема? Давайте предположим, что я хочу описать простой объект, например стакан, используя XML. Зачем я собираюсь использовать XML для этого? Ну, во-первых, это как раз то, для чего и предназначен XML. XML описывает данные. В моем примере, стакан, это и есть данные. В жизни, данными могут быть документы Word, листы электронных таблиц, изображения, книга, запись базы данных, или даже классы C++ или Visual Basic. Во вторых, XML расширяем. XML позволяет мне создавать столько признаков, сколько необходимо для описания данных и эти признаки будут такими, какими я захочу. И, наконец, потому что XML быстро становится стандартом. Если на Марсе есть жизнь, то можете не сомневаться, что они там смогут понять мой XML файл.

Какие основные свойства позволяют описать стакан?

Как бы то же самое выглядело в формате XML?

glass 6 16 ice cube straw water yes

Заметьте, что первая строка файла () имеет специальный вид, пока, просто запомните, что она должна быть тут. Прелесть формата XML в том, что любой может понять, о чем в нем говориться, просто внимательней взглянув на него. Понятно также, что это не единственное из возможных XML описаний стакана. Если я попрошу 10 человек разработать XML описание стакана с одинаковыми свойствами, возможно, все они создадут разные, но верные описания. Вот тут как раз и кроется проблема. Возможно не для нас, людей, но когда компьютер читает XML файл, то было бы отличной идеей, дать ему знать, о чем этот файл. Вот тут и всплывает пространство имен (namespaces) и схемы (schemes). Проще говоря, схемы используются для определения адекватной структуры для XML файла.
Теперь настало время поговорить о нескольких простых правилах XML, которым необходимо придерживаться:

Правило XML #1 : Адекватный XML файл должен в точности соответствовать своей схеме. Но для простоты понимания материала, ни один из моих примеров не будет использовать схемы. Таким образом, строго говоря, ни один из моих примеров не "адекватный". Но, честно говоря, мне все равно. Я не собираюсь строить дом, мне нужно всего лишь повесить картину. Я подробней расскажу об этом позже, когда будем обсуждать объектную модель документов XML.

Правило XML #2 : Если вы программируете на VB, запомните: XML чувствителен к регистру. XML чувствителен к регистру. XML чувствителен к регистру. XML чувствителен к регистру. Напишите это предложение 1000 раз и никогда не забудете.

Правило XML #3 : Тэги принято называть элементами и каждый открывающийся тэг, должен иметь соответствующий ему закрывающийся тэг. Следуя этому правилу, у вас получится правильный XML файл. Это очень важно, потому что до тех пор, пока XML файл не будет правильно оформлен, он не будет проанализирован и не загрузится в объектную модель документов. Заметьте, если элемент не содержит значений и не содержит других (вложенных) элементов, закрывающий тэг может иметь вид вместо более громоздкой конструкции . Можете увидеть такой подход в предыдущем примере ().

Правило XML #4 : Элементы могут содержать атрибуты, а значения атрибутов должны быть заключены в кавычки (одинарные или двойные).

Правило XML #5 : Можно несколько раз использовать имена атрибутов, но имена элементов должны быть уникальны для всего файла. В предыдущем примере, атрибут qty имел различное значение в зависимости от того, в каком элементе он используется ,, или . Значение атрибута зависит от контекста его использования. Тогда как значение элемента всегда означает одно и то же, независимо от того, в каком месте файла атрибут находится. В предыдущем примере, элемент и всегда имеет одно и то же значение во всем нашем документе. например, всегда используется для описания высоты стакана.

Правило XML #6 : В XML есть несколько специальных символов, которые не могут быть использованы напрямую, потому что являются зарезервированными в синтаксисе XML. Поэтому, для использования таких символов, придется использовать зарезервированную конструкцию, начинающуюся с символа & и специального кода, (символ & должен писаться как &) (символ " должен писаться как ") (символ < должен писаться как <) (символ > должен писаться как >) и (символ " должен писаться как "). Вместо этого, также можно использовать инструкцию , где на месте "...." может быть любая последовательность символов, кроме "]]>". Такая конструкция может встречаться в любом месте, но она не может быть вложенной.

2. Объектная модель документов XML

Объектная модель документов XML позволяет программистам загружать содержимое XML файла в память. Как только XML файл загружен таким образом, с ним можно работать, используя свойства, методы и события объектной модели документов. Вот где как раз и проявляется польза XML. Объектная модель документов значительно облегчает выборку и обработку информации XML файла. Я не буду тут рассказывать обо всех возможностях объектной модели документов, расскажу лишь о некоторых основных возможностях, которые помогут в достижении цели этой статьи. Я возьму только что созданный XML файл с описанием стакана, загружу его в объектную модель документов и проделаю несколько действий с ним. Остальные особенности и возможности объектной модели документов я приберегу для следующей статьи, рассказывающей о клиентском XML. Заметьте, не смотря на то, что объектная модель документов очень хороша и удобна для разработчиков, она требует довольно значительного объема системных ресурсов. Поэтому существует еще один метод анализа XML файлов, известный как SAX. Моя статья не претендует на исчерпывающий источник информации по этому вопросу, поэтому было бы полезно также воспользоваться XML SDK.

Давайте посмотрим на пример, используя анализатор Microsoft"s XML версии 3.0 (Microsoft"s XML parser version 3.0 (msxml3.dll)) чтобы разобраться, как же это все работает. Если у вас нет анализатора, то последнюю версию можно скачать с сайта Microsoft.
Предположим, я сохранил пример описания стакана в формате XML в файл "http://web_server/xml/cup.xml" (локальный путь C:\inetpub\wwwroot\xml\cup.xml) и теперь хочу загрузить его в объектную модель документов. Следующий код предполагает, что анализатор уже загружен и работает.

Код на Visual Basic 6.0: (устанавливаем связь с Microsoft XML, v3.0) Dim xmlDoc as MSXML2.DOMDocument30 Set xmlDoc = New DOMDocument30 xmlDoc.async = False xmlDoc.validateOnParse = False xmlDoc.load ("c:\inetpub\wwwroot\xml\cup.xml") msgBox xmlDoc.xml ASP Server-Side код на Visual Basic: Dim xmlDoc Set xmlDoc = Server.CreateObject("Msxml2.DOMDocument.3.0") xmlDoc.async = False xmlDoc.validateOnParse = False xmlDoc.load "/xml/cup.xml" ASP Server-Side код на Java Script: var xmlDoc = Server.CreateObject("Msxml2.DOMDocument.3.0"); xmlDoc.async = false; xmlDoc.validateOnParse = false; xmlDoc.load ("/xml/cup.xml");

Пояснение приведённого кода - пройдемся по коду на VB6

Строка 1: Dim xmlDoc as MSXML2.DOMDocument30

В этой первой строке определяем ссылку на "Microsoft XML, v3.0". В этой строке я определил переменную xmlDoc как ссылку на XML документ. MSXML2 это библиотека (используйте это название, не пытайтесь написать MSXML3, это не будет работать). DOMDocument30 определяет объект XML документа соответствующий версии 3.0. Вы также можете встретить такой код: dim xmlDoc as MSXML2.DOMDocument. Такой конструкцией обычно пользуются, когда не хотят указывать конкретную версию XML документа. В этом случае будет использоваться зарегистрированный по умолчанию в системе анализатор. Проблема может быть только в том, что версия анализатора, зарегистрированная по умолчанию, может отличаться на разных компьютерах. Если вы хотите быть уверенными в том, что написанный вами код будет работать с любой версией анализатора, то не используйте в нем специфических для конкретных версий анализатора конструкций. Потому, что нет никакой гарантии, что у пользователя, который будет пользоваться вашим кодом, установлена имена та версия анализатора, под которую вы писали свой код. Еще одно преимущество разработки кода, независимого от версии анализатора в том, что когда выходит более новая версия анализатора, у нее обязательно будет обратная совместимость с предыдущими версиями, и вам не придется перекомпилировать ваш код.

Строка 2: Set xmlDoc = new DOMDocument30

В этой строке происходит инициализация переменной xmlDoc как нового экземпляра объекта XML документа версии 3.0.

Строка 3: xmlDoc.async = False

Файлы XML могут быть загружены либо в синхронном, либо в асинхронном режиме. Если xmlDoc.async = False, то значит, что содержимое XML фала будет загружено, и только после этого управление будет передано вызывающему процессу. Если xmlDoc.async = True, то значит, что управление будет передано вызывающему процессу сразу, не дожидаясь, пока содержимое XML файла будет полностью загружено.

Строка 4: xmlDoc.validateOnParse = False

Этот код сообщает о том, что анализатор не должен проверять загружаемый XML файл на соответствие своей схеме (validateOnParse = False). Для того, чтобы включить проверку на соответствие схемы, нужно написать validateOnParse = True.

Строка 5: xmlDoc.load ("C:\inetpub\wwwroot\xml\cup.xml")

В этой строке вызывается метод загрузки указанного XML файла. Существует два вида метода загрузки. Первый, который написан в строке 5, загружает файл в объектную модель документов, и при этом нужно обязательно передавать полный путь до XML файла. Второй вариант загрузки предусматривает передачу в качестве параметра xml строку. Такой вид загрузки мог бы быть вызван, например, так: xmlDoc.loadXML("корректная xml строка"). Я покажу, как пользоваться этим способом позже.

Строка 6: MsgBox xmlDoc.xml

Эта строка отображает содержимое загруженного XML файла. В результате мы должны получить тот исходный XML файл, который создали ранее.

2.2. Исследование объектной модели документов XML

Создайте в Visual Basic новый проект и назовите его standard.exe. Вставьте приведенный выше код в метод загрузки главного окна вашего проекта. Убедитесь, что вы объявили ссылку именно на "Microsoft XML v3.0". Для того, чтобы это сделать, нажмите Project-->References, затем пролистайте появившийся список вниз и найдите в нем нужную ссылку. Заметьте, анализатор версии 3.0 должен быть установлен на вашем компьютере, иначе в списке его не будет. Установите точки остановки на последней строке кода (msgbox xmlDoc.xml). Запустите приложение в режиме отладки. Когда процесс выполнения дойдет до точки остановки, вызовите окно "Locals" и посмотрите объектную модель документов. Можно многое узнать, просматривая то, что отображено в этом окне. Окно "Locals" должно быть похоже на то, что изображено на рисунке ниже. Вот некоторые интересные свойства объектной модели документов.

Объектная модель документов XML всегда содержит два узла верхнего уровня:

  • Item1 это корень ветви элементов документа (не обращайте на нее внимания)
  • Item2 на самом деле первый элемент документа (запомните это)

nodeName или baseName - могут быть использованы при поиске имени элемента или атрибута.
nodeType - используйте для того, чтобы получить тип текущего узла.
nodeValue - используете для того, чтобы узнать значение данных узла.
childNodes - это коллекция узлов-потомков. Они могут быть узлами элементов, текстовыми узлами и узлами CDATA. Могут быть и другие типы узлов, про которые я сейчас рассказывать не стану, но вы сможете узнать все про них в XML SDK.
attributes - это коллекция узлов атрибутов текущего элемента.
length - используется для определения количества узлов в дереве непосредственно принадлежащих текущему.
xml - это свойство присутствует во всех узлах и может быть использовано для представления текущей позиции в документе. XML строка начинается с текущего узла и проходит вниз до конца дерева. Это очень полезное свойство. Поэкспериментируете с ним и увидите, что получится.

2.2.2. Узлы элементов

Узел элементов может содержать узлы потомки элементов, атрибутов, текста или CDATA. Из рисунка ниже видна следующая информация об узле "SOLID":

nodeType - Тип текущего узла = NODE_ELEMENT - т.е. текущий узел является элементом.
nodeName или baseName или tagName - Название текущего узла (элемента) = SOLID.
Его родительский элемент CONTENTS имеет 4 потомков.
Это можно увидеть на следующем рисунке, но SOLID имеет одного потомка, который имеет текстовый тип данных.
text - "ice cube" это сокращенный метод, позволяющий получить значение текущего узла без перемещения к текстовому узлу потомка.

2.2.3. Узлы атрибутов

Узлы атрибутов могут состоять только из текстовых или CDATA узлов-потомков. На следующем рисунке показано, какая информация может быть получена об узле "qty":

nodeType - Тип текущего узла = NODE_ATTRIBUTE - текущий узел является атрибутом.
nodeName или baseName - Имя текущего узла (Атрибутов) = qty

Из следующего рисунка также понятно, что qty имеет одного потомка, который имеет текстовый тип данных.
text или value - "2" это сокращенный метод, позволяющий получить значение текущего узла без перемещения к текстовому узлу потомка.

2.2.4. Текстовые узлы и узлы CDATA

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

nodeType - Тип текущего узла = NODE_TEXT - текущий узел содержит текстовые данные.
nodeName - Имя текущего узла (текстового) = #text - все текстовые узлы называются #text
data или text или value - "2" - это текущие данные узла.

2.2.5. Ошибки при загрузке документа

Секция parseError объектной модели документов может оказаться полезно при выявлении проблем, возникающих при загрузке XML документа. Если я удалю закрывающий тег от OTHER в файле нашего примера и попытаюсь запустить программу еще раз, то получу следующий результат. Первая часть полезной информации, это то, что наш nextSibling теперь содержит значение Nothing. Теперь, если вы посмотрите на childNodes, вы можете увидеть, что поле length теперь равно 0. Оба этих признака говорят о том, что наш XML документ не был загружен. Чтобы разобраться почему, я открываю узел parseError и получаю всю информацию об ошибках.

Итак, я показал вам, как загрузить XML файл в объектную модель документов, но что с ним там делать? Одна из основных возможностей, которой вы сможете пользоваться это выполнять различные запросы к XML документу. Для этого вы конечно можете просматривать весь документ до тех пор, пока не найдете информацию которую ищите. Но наиболее предпочтительный способ, это использование одного из двух методов класса DOMDocument. Два метода используемые для поиска узлов в нашем предыдущем примере могли бы выглядеть как xmlDoc.SelectSingleNode(patternString) - для получения искомого узла, или xmlDoc.SelectNodes(patternString) - для получения списка искомых узлов. Параметр patternString как раз и является запросом. Он может быть сформирован одним из двух способов. Либо как XSL запрос, либо как XPath запрос. Более новый и предпочтительный способ создавать запросы к XML документу, это XPath. Формат patternString должен быть установлен заранее, перед первым вызовом любого из двух методов запроса данных, иначе по умолчанию будет использоваться XSL способ формирования запросов. Для установки типа формирования patternString используйте setProperty("SelectionLanguage", "format"). Для того, чтобы изменить запросы в нашем примере таким образом, чтобы использовался способ XPath, я добавлю следующую команду: setProperty("SelectionLanguage","XPath"). По-моему, XPath это самая важная технология в XML которую следует изучить. Я приведу несколько простых XPath запросов. Хорошим началом для изучения этой технологии может служить Microsoft XML SDK. Еще одним способом для объяснения этого, могло бы быть написание простого приложения на Visual Basic, которое позволяет вводить запросы и выводить результат. Вы, возможно, найдете какие-нибудь бесплатные приложения, которые делают то же самое, но XPath довольно новый и может не вполне поддерживаться этими приложениями.

2.3.1. Использование XPATH для выполнения запросов к объектной модели документов

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

ОТЛИЧНО! Давайте теперь добавим еще один запрос, который позволит нам определить, есть ли у стакана крышка или нет. Добавьте следующий код в конец предыдущего:

Set objNode = xmlDoc.selectSingleNode("/CUP/LID") if objNode.text="yes" then MsgBox "We have a lid" else MsgBox "No lid on this cup" end if

Пройдемся по коду строка за строкой:

Строка 1 : Dim objNode As IXMLDOMNode

В этой строке определяется переменная objNode типа узел XML документа. Важно понимать, что узел XML документа это тоже объект. Это не значение. Он состоит сам из себя, также как и его атрибуты и потомку (childNodes). Этим способом вы можете отсекать ненужные ветви дерева, выбирая только нужные.

Строка 2 : Dim objListOfNodes As IXMLDOMNodeList

В этой строке определяется переменная objListOfNodes имеющая тип списка узлов XML документа (группы узлов).

Строка 3 : xmlDoc.setProperty "SelectionLanguage", "XPath"

Эта строка устанавливает способ формирования patternString как XPath.

Строка 4 : MsgBox "Your cup contains the following items:"

Строка 5 : Set objListOfNodes = xmlDoc.selectNodes("//CONTENTS/*[@qty>0]")

Эта строка выполняет XPath запрос, который вернет группу узлов и сохранит их в переменной objListOfNodes. Запрос разбит на следующие части:

  • //CONTENTS - взять все элементы CONTENTS в XML документе. Заметьте: // - это краткое обозначение для всего содержимого XML документа.
  • /* - из списка элементов CONTENTS взять все (* - используется для указания всех) элементы-потомки. Это сокращает полученный результат до четырех узлов элементов (). Эти четыре узла попадают напрямую под узел CONTENTS.
  • [@qty>0] - проверить каждый элемент-потомок на то, чтобы его атрибут qty (@ - означает атрибут) был больше 0. Если это условие не выполняется, узел отбрасывается. Все, что внутри в XPath запросе может принимать значения True или False. Если результат True, то узел сохраняется. Если результат False, то узел отбрасывается. После этого наш результат сокращается до трех узлов (

Строка 6-8 : For Each objNode In objListOfNodes / MsgBox objNode.Text / Next

Эти строки отображают значения каждого узла элемента, которые соответствуют запросу. ("ice cube" , "straw" , "water").

Строка 9 : Set objNode = xmlDoc.selectSingleNode("/CUP/LID")

Эта строка возвращает все элементы LID, которые принадлежат элементу CUP, который, в свою очередь, порожден от корня дерева (когда запрос начинается с /, то это означает что начинать нужно с корня). Это очень похоже на путь к файлу или папке. В нашем примере, этот запрос вернет элемент LID, который содержит значение "yes". Важно тут то, что я указал запросу начинать с корневого элемента XML документа. Запросы не всегда начинают выполняться с корневых элементов, обычно они начинаются с текущего узла. В нашем примере это не имеет значения, поскольку текущим узлом (xmlDoc) и является корневой элемент XML документа (но не во всех случаях это так).

Строка 10-15 : if objNode.text="yes" then / MsgBox "We have a lid" /
else / MsgBox "No lid on this cup" /end if

Эта строка отображает сообщение "We have a lid" потому, что текстовое свойство элемента LID "yes".

3. Преобразование ADO в XML

Теперь, когда вы поняли основы XML, давайте создадим элемент управления ActiveX, который будет конвертировать набор данных ADO в XML формат. Цель в том, чтобы получить наименования книг из таблицы Titles базы данных Pubs и вернуть их в формате XML. Результат, который получится я буду использовать в своей следующей статье. Вы можете сказать, ADO имеет свои собственные методы для сохранения результата в формате XML, правильно? Да, но если доверить это ADO, то в итоге я получу XML файл в таком ужасном формате, что с ним невозможно будет работать. ADO создаст XML файл с использованием пространства имен, а мне сейчас это совсем не нужно. Во-вторых, ADO создаст XML файл, который будет представлен в форме атрибутов. Иными словами, каждая запись станет элементом и каждое поле - атрибутом:

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

data from table data from table data from table data from table data from table datafrom table datafromtable

Кстати, то, что я только что сделал, это создал схему для моей XML строки. Теперь, если мне нужно сверить структуру XML документа со схемой, все что мне останется сделать, это преобразовать схему в правильный формат. То есть в синтаксис DTD или XDR. Заметьте, что я добавил некоторые атрибуты к каждому элементу . Одна из причин этого в том, что эта информация может быть использована клиентом. Prettyname могут быть использованы как метки данных. Атрибут datatype мог бы быть использован для проверки данных на стороне клиента. Но чтобы быть честным, истина причина того, что появились эти атрибуты в том, что они имеют особое назначение в шаблоне XSL фала, который я часто использую для построения секции where SQL запросов. Может быть, я скоро опубликую статью, демонстрирующую этот подход. Шаблон на самом деле очень полезный. Когда XML структура применяется к данным из таблицы Titles, результат будет выглядеть следующим образом:

The Busy Executive"s Database Guide BU1032 The Busy Executive"s Database Guide business 19.99 4095 An overview of available database systems with emphasis on common business applications. Illustrated. 6/12/1991 Cooking with Computers: Surreptitious Balance Sheets BU1111 Cooking with Computers: Surreptitious Balance Sheets business 11.95 3876 Helpful hints on how to use your electronic resources to the best advantage. 6/9/1991

Теперь я получил что-то, с чем можно работать!

Листинг 1 - CUP.XML

glass 6 16 ice cube straw water yes

Dim xmlDoc As MSXML2.DOMDocument30 Set xmlDoc = New DOMDocument30 xmlDoc.async = False xmlDoc.validateOnParse = False xmlDoc.Load ("c:\inetpub\wwwroot\xml\cup.xml") MsgBox xmlDoc.xml Dim objNode As IXMLDOMNode Dim objListOfNodes As IXMLDOMNodeList xmlDoc.setProperty "SelectionLanguage", "XPath" MsgBox "Your cup contains the following items" Set objListOfNodes = xmlDoc.selectNodes("//CONTENTS/*[@qty>0]") For Each objNode In objListOfNodes MsgBox objNode.Text Next Set objNode = xmlDoc.selectSingleNode("/CUP/LID") If objNode.Text = "yes" Then MsgBox "We have a lid" Else MsgBox "No lid on this cup" End If

Листинг 3 - Элемент управления ActiveX: ADO в XML (WebClass.dll)(xmlControl.cls)

Option Explicit "Declare Database variables Private m_dbConnection As New ADODB.Connection Private m_dbCommand As ADODB.Command Private m_adoRs As ADODB.Recordset Private m_adoErrors As ADODB.Errors Private m_adoErr As Error Public nCommandTimeOut As Variant Public nConnectionTimeOut As Variant Public strConnect As Variant Public strAppName As String Public strLogPath As String Public strDatabase As String Public strUser As String Public strPassword As String Public strServer As String Public strVersion As String Public lMSADO As Boolean "Private Global Variables Private gnErrNum As Variant Private gstrErrDesc As Variant Private gstrErrSrc As Variant Private gstrDB As String Private gstrADOError As String Private Const adLeonNoRecordset As Integer = 129 Private gtableName(6) As String Private gcolumnName(6) As String Private gprettyName(6) As String Private gdatatype(6) As String Private gfilter(6) As String Private Function OpenDatabase() If Len(strConnect) = 0 Then "устанавливаем значения по умолчанию If Len(strDatabase) = 0 Then strDatabase = "pubs" End If If nConnectionTimeOut = 0 Then nConnectionTimeOut = 600 End If If nCommandTimeOut = 0 Then nCommandTimeOut = 600 End If If Len(strAppName) = 0 Then strAppName = "xmlControl" End If If Len(strUser) = 0 Then strUser = "sa" End If If Len(strPassword) = 0 Then strPassword = "" End If strConnect = "Provider=SQLOLEDB.1; " & _ "Application Name=" & strAppName & _ "; Data Source=" & strServer & "; Initial Catalog=" & strDatabase & "; " & _ " User ID=" & strUser & "; Password=" & strPassword & ";" End If "подключаемся к SQL Server и открываем базу данных On Error GoTo SQLErr "Включаем обработчик ошибок With m_dbConnection .ConnectionTimeout = nConnectionTimeOut .CommandTimeout = nCommandTimeOut .Open strConnect "открываем базу данных, используя строку подключения End With On Error GoTo 0 "выключаем обработчик ошибок OpenDatabase = True "база данных открыта успешно Exit Function SQLErr: Call logerror("OPEN") OpenDatabase = False End Function Private Function BuildSQLwhere(tmpWhere) As String "Это на будущее End Function Public Function GetTitlesXML(Optional xmlWhere As Variant) As String Dim whereClause As String Dim strSQL As String Call OpenDatabase "открываем базу данных pubs If IsMissing(xmlWhere) Then "когда запрос не прошел whereClause = "" Else whereClause = BuildSQLwhere(xmlWhere)"конвертируем запрос в правильный sql End If "инициализируем sql выражение которое будет запрашивать заголовки книг strSQL = "select title_id,title,type,price,ytd_sales,notes,pubdate from titles " & whereClause Call NewRecordSet "создаем набор данных "устанавливаем cursorlocation m_adoRs.CursorLocation = adUseClient "открываем набор записей m_adoRs.Open strSQL, m_dbConnection, adOpenForwardOnly, adLockReadOnly, adCmdText "отключаемся от набора данных Set m_adoRs.ActiveConnection = Nothing On Error GoTo 0 "выключаем обработчик ошибок "закрываем базу данных и освобождаем подключение Call CloseDatabase If m_adoRs.EOF Then GetTitlesXML = "" "запрос не вернул ни одного значения Else If lMSADO Then GetTitlesXML = msado(m_adoRs) "конвертируем набор данных в Microsoftado-->xml Else GetTitlesXML = ADOtoXML(m_adoRs, True) "convert the ado recordset to custom xml End If End If "закрываем набор данных Call CloseRecordset Exit Function SQLErr: Call logerror(strSQL) End Function Private Function ADOtoXML(tmprs As ADODB.Recordset, tmpMP As Boolean) As String Dim adoFields As ADODB.Fields "объявляем коллекцию для хранения полей Dim adoField As ADODB.Field "используется для получения каждого поля из коллекции Dim xmlDoc As msxml2.DOMDocument30 Dim tmpLine As String "хранит xml представление каждой книги Dim tmpXML As String "служит для конкатенации xml строк Dim i As Integer If tmprs.EOF Then "запрос не вернул ни одну запись ADOtoXML = "" Exit Function Else Set adoFields = tmprs.Fields "создаем коллекцию полей End If tmpXML = "" "все книги будет заключены в тег Do Until tmprs.EOF "цикл по каждой строке в наборе данных i = 0 " I - индекс ado поля, который начинается с 0 - первое поле будет field(0) tmpLine = "" & tmprs("title") & vbCrLf For Each adoField In adoFields "цикл по всем полям "строим xml тег и его атрибуты для текущего поля tmpLine = tmpLine & "" & adoField.Value tmpLine = tmpLine & "" & vbCrLf i = i + 1 "переходим на следующее поле Next tmpXML = tmpXML & tmpLine & "" & vbCrLf "закрывающий тег после последнего поля tmprs.MoveNext "следующий заголовок Loop Set adoField = Nothing "уничтожаем объект-поле Set adoFields = Nothing "уничтожаем объект-коллекцию полей tmpXML= tmpXML & "" & vbCrLf "закрывающий тег Set xmlDoc = New msxml2.DOMDocument30 "создание xmlDOM xmlDoc.async = False "ждем когда документ загрузится xmlDoc.validateOnParse = False "не сверяемся со схемой xmlDoc.loadXML(tmpXML) "загружаем строку в объектную модель документов On Error Resume Next "если файл не существует, то обрабатываем эту ошибку Kill("c:\temp\custom.xml") "стираем файл если он существует On Error GoTo 0 "говорим обработчику ошибок прерываться при обнаружении ошибки xmlDoc.save ("c:\temp\custom.xml") "сохраняем xml в файл ADOtoXML=xmlDoc.xml "возвращает xml строку Set xmlDoc=Nothing "уничтожаем объектную модель документов End Function Private Function msado(tmprs As ADODB.Recordset) As String Dim xmlDoc As msxml2.DOMDocument30 On Error Resume Next "если файла не существует, получаем ошибку Kill ("c:\temp\msado.xml") "стираем файл, если он существует On Error GoTo 0 " говорим обработчику ошибок прерываться при обнаружении ошибки tmprs.save "c:\temp\msado.xml", adPersistXML " сохраняем xml в файл Set xmlDoc = New msxml2.DOMDocument30 "создаем объектную модель документов xml xmlDoc.async = False "ждем загрузки xml документа xmlDoc.validateOnParse = False "не сверяемся со схемой xmlDoc.Load ("C:\temp\msado.xml") "загружаем файл в объектную модель документов msado = xmlDoc.xml "возвращаем xml строку Set xmlDoc = Nothing "уничтожаем объектную модель документов End Function Private SubCloseRecordset() "закрываем набор данных m_adoRs.Close Set m_adoRs =Nothing End Sub Private Sub NewRecordSet() Set m_adoRs= Nothing Set m_adoRs=New ADODB.Recordset End Sub Private Sub CloseDatabase() m_dbConnection.Close Set m_dbConnection =Nothing End Sub Private Sub logerror(errSQL As String) Dim hFile As Integer Dim expFile As String On Error GoTo 0 gnErrNum = Err.Number gstrErrDesc =Err.Description gstrErrSrc = Err.Source Set m_adoErrors = m_dbConnection.Errors For Each m_adoErr In m_adoErrors gstrADOError = m_adoErr.Description & "," & CStr(m_adoErr.NativeError) _ & "," & CStr(m_adoErr.Number) & "," & m_adoErr.Source _ & "," & CStr(m_adoErr.SQLState) Next hFile =FreeFile If Len(strLogPath) = 0 Then strLogPath = "C:\temp\" End If expFile = strLogPath & strAppName & ".err" Open expFile For Append As #hFile Print #hFile,"**********************************" Print #hFile, Now() Print#hFile, "**********************************" Print #hFile,"Subroutine: " & tmpPro Print #hFile, "Error Number:" & gnErrNum Print#hFile, "Error Description: " & gstrErrDesc Print #hFile, "Error Source:" & gstrErrSrc Print #hFile, "Ado error String: " & gstrADOError Print #hFile, "Bad SQL: " & errSQL Close #hFile End Sub Private Sub Class_Initialize() strVersion = "xmlControl Version 1.1" "title_id,title,type,price,ytd_sales,notes,pubdate gtableName(0) = "titles" gcolumnName(0) = "title_id" gprettyName(0) = "Title Identification Number" gdatatype(0) = "number" gfilter(0) = "" gtableName(1) = "titles" gcolumnName(1) = "title" gprettyName(1) = "Title of the Book" gdatatype(1) = "text" gfilter(1) = "" gtableName(2) = "titles" gcolumnName(2) = "type" gprettyName(2) = "Type of Book" gdatatype(2) = "text" gfilter(2) = "" gtableName(3) = "titles" gcolumnName(3) = "price" gprettyName(3) = "Price of the Book" gdatatype(3) = "number" gfilter(3) = "" gtableName(4) = "titles" gcolumnName(4) = "ytd_sales" gprettyName(4) = "Year to date sales" gdatatype(4) = "number" gfilter(4) = "" gtableName(5) = "titles" gcolumnName(5) = "notes" gprettyName(5) = "Notes about the book" gdatatype(5) = "memo" gfilter(5) = "" gtableName(6) = "titles" gcolumnName(6) = "pubdate" gprettyName(6) = "Date Published" gdatatype(6) = "date" gfilter(6) = "" End Sub

Листинг 4 - Тестовое приложение на VB для проверки WebClass

Private Sub Command1_Click() Dim objWC As xmlControl Dim xml As String Set objWC = New xmlControl objWC.strDatabase = "pubs" objWC.strServer = "ltweb" objWC.strUser = "sa" objWC.strPassword = "" objWC.lMSADO = Option2.Value objWC.strAppName = "Article1" Text1.Text = objWC.getTitlesXML End Sub

Листинг 5 - ASP для тестирования WebClass

Первые шаги

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


< tutorial >
< title > "Заметки об XSL"
< author > Леонов Игорь Васильевич

Первая строка информирует браузер о том, что файл имеет формат XML. Атрибут version является обязательным. Атрибут encoding не является обязательным, но если у вас в тексте есть русские буквы, то необходимо вставить этот атрибут, в противном случае XML-файл просто не будет обрабатываться, - вы получите сообщение об ошибке.

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

Элементы могут иметь атрибуты, значения которых тоже могут обрабатываться в соответствии с шаблоном.

На верхнем уровне XML-файла всегда находится один элемент. То есть файл вида


< tutorial >
< title > "Заметки об XSL"
< author > Леонов Игорь Васильевич

< tutorial >
< title > "Введение в CSP"
< author > Леонов Игорь Васильевич

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


< knowledgeDatabase >
< tutorial >
< title > "Заметки об XSL"
< author > Леонов Игорь Васильевич

< tutorial >
< title > "Введение в CSP"
< author > Леонов Игорь Васильевич

< /knowledgeDatabase >

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

Перейдем теперь к шаблону преобразования - к XSL-файлу. Задача XSL-файла - преобразовать дерево XML-файла в другое дерево, которое, например, будет соответствовать формату HTML и может быть изображено на экране браузера с учетом форматирования, выбора шрифтов и т.п.

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


Рассмотрим теперь текст XSL-файла

< xsl:stylesheet version =" 1.0" xmlns:xsl =" http://www.w3.org/TR/WD-xsl ">
< xsl:template match =" /">
< p >< strong >< xsl:value-of select =" //title""/>
< p >< xsl:value-of select =" //author"/>

Первая строка файла содержит тег элемента xsl:stylesheet . Атрибуты элемента - номер версии и ссылка на пространство имен. Эти атрибуты элемента xsl:stylesheet являются обязательными. В нашем случае пространство имен - это все имена элементов и их атрибутов, которые могут использоваться в XSL-файле. Для XSL-файлов ссылка на пространство имен является стандартной.

Заметим, что XSL-файл является одной из разновидностей XML-файлов. Он не содержит пользовательских данных, но формат его тот же самый. Файл содержит элемент верхнего уровня xsl:stylesheet , а далее идет дерево правил преобразования.

В настоящем документе мы не будем подробно пояснять, что означает каждый элемент XSL-файла. Мы будем приводить различные примеры и показывать результат в каждом примере. Читатель сможет самостоятельно сопоставить различные элементы XSL-файла и инициируемые этими элементами преобразования исходного XML-файла с пользовательской информацией.

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

В первом примере мы посмотрели, как с помощью элемента xsl:value-of можно вывести в HTML-формате содержание элемента (текст, заключенный между тегами). Теперь мы посмотрим, как при помощи того же самого элемента можно вывести значение атрибута элемента.

Рассмотрим следующий XML-файл ex02-1.xml







В этом файле информация хранится не в содержании элементов, а в виде значений атрибутов. Файл ex02-1.xsl имеет вид




.
, .



Обратите внимание на синтаксис ссылки на атрибут элемента - //dog/@ name . Имя элемента и имя атрибута разделены парой символов "/@ ". В остальном синтаксис тот же самый, что и для ссылки на содержание элемента.

Результат имеет следующий вид:

Собака: Шарик. 18 кг, рыжий с черными подпалинами.

Обратим теперь внимание на следующий момент. В XSL-файле мы никак не использовали элемент tutorial . На самом деле можно было использовать полный путь. Перепишем наш XML-файл, увеличив глубину дерева (ex02-2.xml)









  • Сергей Савенков

    какой то “куцый” обзор… как будто спешили куда то