PHP5_nachinayushim

346 Глава 8

ность, которая делает XML столь мощной технологией, заключается в том, что удобо+ читаемость XML+документов и свойства DTD или XML Schema позволяют узнать, что в частности означают определенные элементы и атрибуты.

Основные части XML-документа

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

XML+документ должен содержать строку xml version, которая может вклю+ чать в себя объявление кодировки символов.

Корректный XML+документ содержит DTD или XML Schema либо ссылку на одно из этих определений, если они хранятся вне документа.

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

XML+документы могут содержать дополнительные компоненты, такие как ин+ струкции для определенных приложений; CDATA+разделы, которые могут содер+ жать специальные символы, входящие в сценарии, но не допустимые в обыч+ ных XML+данных; записи, комментарии, ссылки (например, псевдонимы для специальных символов), текст и другие объекты.

Ниже приведен пример правильно сформированного и корректного XML+документа:

<?xml version="1.0" standalone="no"?>

<!DOCTYPE Client SYSTEM "http://www.example.com/dtds/client.dtd"> <clients>

<client>Joe</client>

<client>Jim</client>

</clients>

Обратите внимание, что ссылка на внешнее DTD+определение задана с помощью URL. Это означает, что документ может быть проверен путем чтения указанного DTD и проверки документа на соответствие DTD+определению. Конечно, можно самому прочитать документ и сравнить его с элементами, атрибутами и другими компонента+ ми, определенными в DTD, однако существует множество приложений, которые спо+ собны автоматически проверять корректность XML+документа по DTD+определению или XML+схеме. А поскольку DTD или схема доступны непосредственно в документе или в Web, приложения могут легко выполнять функцию проверки автоматически во вре+ мя синтаксического разбора документа.

Правильно сформированные XML-документы

Вправильно сформированном XML+документе соблюден синтаксис, описанный

вспецификации XML. Синтаксис, естественно, определяется несколькими базовыми правилами; наиболее распространенные из них перечислены ниже.

Существует только один родительский элемент, содержащий все остальные элементы в документе.

XML 347

XML+документ должен (хотя это и не является строгим правилом) начинаться с XML+объявления, содержащего номер используемой версии XML. Например:

<xml version="1.0">

В строку с номером версии XML можно включать объявления кодировок сим+ волов, а если используется кодировка, отличная от UTF+8 или UTF+16, то это обязательно. Код может выглядеть так:

<xml version="1.0" encoding="UTF-8">

Если XML+документ содержит DTD или ссылку на XML Schema, то они должны появляться перед первым элементом в документе.

XML+документ может составляться из начальных и конечных тегов (которые очень похожи на HTML+теги) или из одинарных тегов с терминатором (как тег <br/> в XHTML). В отличие от HTML не допускается использовать элементы, имеющие только начальный тег без терминатора. Элементы с начальными и конечными тегами считаются не пустыми (т.е. они могут заключать в себе какое либо содержимое), тогда как в пустых тегах содержимого нет (пустые элементы иногда сами по себе обозначают что+либо, как, например, тег <br/> в XHTML):

<client>John Doe</client> <break />

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

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

//неправильно

<parent><child></parent></child> //правильно

<parent><child></child></parent>

CDATA+разделы (например, разделы данных, которые составляют сценарии) должны быть заключены в теги [CDATA и ]].

XML+элементы не могут иметь имя, в котором используется комбинация ‘‘xml’’, ‘‘XML’’ или любая другая комбинация букв верхнего и нижнего регистров в данной последовательности. Имена должны начинаться с буквы, символа подчеркивания или двоеточия, но на практике двоеточие не используется. Имена чувствительны к регистру. В именах также можно использовать цифры, дефис и точку, но только после первого символа имени.

Комментарии заключаются в такие же теги, как и HTML+комментарии (<!-- и -->).

Использование XML-элементов и атрибутов

XML+элементы и их атрибуты формируют иерархическую структуру XML+ документа и заключают в себе его содержимое (содержимым XML+документа являют+ ся его данные). Хотя в документе может быть только один корневой элемент. Корневой

348 Глава 8

элемент может содержать множество элементов с одинаковыми именами (эти эле+ менты часто называются дочерними элементами), в свою очередь дочерние элементы тоже могут содержать множество элементов с одинаковыми именами. Поэтому доку+ мент может выглядеть так:

<clients>

<client ID="1">Joe</client> <orders>

<order ID="1">ProductA</order> <order ID="2">ProductB</order>

</orders>

<client ID="2">Jim</client> <orders>

<order ID="1">ProductA</order> <order ID="2">ProductB</order>

</orders>

<client></client>

</clients>

Очевидно, что одна часть данных документа помещена в элементы (имя каждого клиента находится между начальным и конечным элементами client), а другая часть данных представлена в виде значений атрибутов (идентификаторы клиентов и их за+ казов указываются в атрибутах элементов client и order).

Когда же следует использовать атрибут и когда элемент, содержащий данные? На этот счет нет жесткого правила. Однако на практике рекомендуется использовать эле+ мент тогда, когда существует вероятность, что одни и те же данные придется указывать несколько раз (например, в настоящее время у клиента может быть только один заказ, но можно ожидать, что в дальнейшем у этого клиента будет несколько заказов). Исполь+ зовать атрибут следует, когда есть уверенность, что данные появляются только однажды (например, каждый клиент может иметь один и только один идентификатор).

Корректные XML-документы: DTD-определения и XML-схемы

DTD+определения представляют собой специальные документы, написанные в фор+ мате EBNF (Extended Backus Naur Format ++++++ расширенный формат Бэкуса+Наура), кото+ рый не является XML+языком и поэтому его синтаксический анализ весьма сложен. В DTD+определениях задаются ограничения на XML+элементы, атрибуты, содержимое и т.д. XML+схемы служат той же цели, но написаны на языке XML Schema; их можно легко анализировать и обрабатывать в том же приложении, которое используется для чтения XML+документа. XML+схемы также более удобны для определения деталей элементов и атрибутов (таких как типы данных, диапазоны значений и т.д.), чем DTD. По этой причине многие создатели XML+документов предпочитают использовать XML+схемы. Перед первым элементом XML+документа могут задаваться ссылки, как на DTD+опре+ деления, так и на XML+схемы. Кроме того, существуют другие способы включения DTD+ определений и XML+схем в XML+документы (эти способы рассматриваются ниже).

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

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

350 Глава 8

ismap (ismap) #IMPLIED

>

<!-- usemap указывает на элемент карты-изображения, который может присутствовать в текущем документе или во внешнем документе, хотя последний случай поддерживается не так широко -->

В приведенном выше примере (код написан в формате EBNF) в первой строке, ко+ торая следует за комментариями, имеется идентификатор ELEMENT, имя элемента img

исвойство EMPTY (элемент не содержит данных между несуществующими начальным

иконечным тегами). Однако несмотря на то, что элемент формально пуст, его атри+ бут src содержит данные в форме URI+адреса (в данном случае это то же самое, что

иURL), указывающего на месторасположение графического файла.

После идентификатора ELEMENT следует перечень атрибутов, которые можно включать в тег img в XHTML+документе. Читатели, знакомые с HTML и XHTML, не+ сомненно догадаются, что атрибут src представляет собой URL (или URI), который указывает на месторасположение файла изображения, а также на то, что данный ат+ рибут является обязательным (REQUIRED).

Таким образом, данная часть DTD для XHTML+документов указывает на то, что в та+ кие документы допускается включать элемент IMG. Если в каком+либо XHTML+ документе указана ссылка на данное DTD+определение (на все определение, а не толь+ ко на эту часть) и документ включает в себя элемент img с соответствующим атрибу+ том src, то можно сказать, что данный документ корректен (по крайней мере, если рассматривать элемент img). Однако если попытаться включить в документ элемент с именем imge, image или images, то XML+анализатор, проверяющий данный документ, сгенерирует ошибку, потому что в DTD данные элементы не определены и, таким об+ разом, документ не является корректным. Следует также отметить, что хотя в HTML+ документе элемент img можно не закрывать, в XHTML+документе правильное закры+ тие этого элемента является обязательным.

Ссылки на DTD-определения и XML-схемы

Для проверки XML+документа в нем должна присутствовать ссылка на внешний файл, содержащий DTD+определение или XML+схему, либо в данный документ долж+ но быть включено само DTD+определение или XML+схема. Ссылки на XML+схемы бо+ лее сложны, поэтому сначала рассмотрим ссылки на DTD+определения.

Для создания ссылки на внешнее DTD+определение используется объявление DOCTYPE. Данное объявление предоставляет некоторую информацию о том, как об+ наружить DTD, а также имя данного DTD. Например, следующий код показывает, как с помощью URL+адреса задается ссылка на DTD:

<!DOCTYPE html

PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Идентификатор html после <!DOCTYPE в первой строке указывает, что корневой эле+ мент имеет имя html и является обязательным. Если DTD ++++++ внешний документ, то это определение может находиться где угодно и идентифицируется по URI+идентифи+ катору, который понятен и доступен приложению, а не только по URL+адресу в Internet.

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

XML 351

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

xmlns = "http://www.w3.org/1999/xhtml"

Данный URL+адрес представляет официальное пространство имен XHTML. Имена элементов и атрибутов для данного пространства имен определены внутри XHTML DTD, а атрибут xmlns служит только для определения пространства имен для корне+ вого элемента XHTML+документа (тега html). Такой способ определения пространст+ ва имен для корневого элемента также подходит для определения пространства имен для остальных элементов и атрибутов документа.

Внешние XML-схемы

Сослаться на XML+схему можно, указав с помощью URI расположение документа XML+схемы. Обычно для этого в XML+документе используется атрибут xmlns как часть корневого элемента. Значением данного атрибута является месторасположение схемы. Так определяется пространство имен и программа+анализатор ‘‘знает’’, где ис+ кать данную XML+схему.

Чтобы задать ссылку на XML+схему, в корневой элемент можно добавить атрибут xmlns:

<?xml version="1.0" encoding="UTF-8"?>

<customer xmlns="http://www.example.com/customer.xsd" cust_id="1"> <cust_name>John Doe</cust_name>

</customer>

Естественно, в данном случае предполагается, что документ XML+схемы уже напи+ сан, расположен в корневом каталоге Web+сайта http://www.example.com и назы+ вается customer.xsd, а также что в нем определены элементы customer (с атрибу+ том cust_id) и cust_name. Хотя в данной книге подробности написания XML+схем не рассматриваются, достаточно сказать, что XML Schema ++++++ гораздо более развитый язык для определения элементов, атрибутов и других компонентов языка, соответст+ вующего XML. Кроме того, он проще в обработке, поскольку XML Schema написан со+ гласно главным принципам XML+спецификации.

Для документов, которые можно сверить с XML+схемой, с помощью атрибута xmlns можно объявлять любое количество пространств имен, каждое из которых бу+ дет связано с внешней XML+схемой. Например, можно использовать одну XML+схему, в которой элемент farm означает площадь, отведенную под сельскохозяйственные нужды, и другую схему, в которой элемент farm означает несколько серверов, выпол+ няющих одну и ту же задачу. Если понадобится создать XML+документ, использующий оба элемента (например, описывающий, как ферма управляет своими серверами), то придется найти какой+либо способ, чтобы отличать эти элементы.

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

xmlns:agri = "http://www.example.com/agricultural.xml" xmlns:serv = "http://www.example.com/server.xml"

352 Глава 8

Впоследствии любой элемент с префиксом agri: будет определяться схемой agricultural.xml, а любой элемент с префиксом serv: будет определяться схемой server.xml. Это предотвратит путаницу в значении элементов.

Написание XML-документов с помощью XHTML

Для XHTML+документа также требуется указывать пространство имен. DTD+опре+ деления не допускают множественных ссылок, но задать одно пространство имен все+ таки можно. Более того, этого требует спецификация XHTML.

Чтобы написать XHTML+документ, сначала необходимо указать номер используе+ мой версии XML, ввести объявление DOCTYPE, которое ссылается на XHTML DTD, а затем вставить атрибут xmlns, указывающий на пространство имен для данного до+ кумента. Вставка атрибута xmlns в корневой элемент приводит к тому, что корневой элемент и все его дочерние элементы по умолчанию определяются заданным DTD. Рассмотрим пример:

<?xml version="1.0" encoding="UTF-8"?>

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

<HEAD>

<title>Пример XHTML-документа</title> </head>

<body>

<p>Данный документ представляет собой пример XHTML-документа. Документ может содержать изображения <img

src="http://www.example.com/images/image.gif" />, а также

гиперссылки <a href="http://example.com/">example.com</a>

и любые другие HTML-элементы. </p>

</body>

</html>

Данный документ выглядит почти так же, как и обычный HTML+документ, а если сохранить его с расширением .htm или .html, то в большинстве браузеров он будет отображаться как обычная Web+страница, написанная на HTML. Вместе с тем данный документ соответствует XML+спецификации и является не только правильно сформи+ рованным, но и корректным. Если сохранить данный документ с расширением .xml, то в большинстве браузеров он будет отображаться в XML+формате.

Web-службы

Еще одним примером эффективности XML является конструкция Web+служб. Web+ службой (Web Service) называется модуль программной логики, доступный через Internet, а название ‘‘XML Web+служба’’ применимо к Web+службам, доступ к которым можно получить посредством XML+языков.

Как работают Web+службы и почему они считаются такими полезными? Вспомним, как определяется, а затем вызывается функция в PHP+программе. Сначала програм+ мист пишет функцию, назначает ей имя, перечень параметров и добавляет всю необ+ ходимую для ее работы программную логику. Затем при необходимости функцию можно вызывать, просто указав ее имя и передав ей соответствующие параметры.

Однако предположим, что то же самое можно было бы сделать через Internet, об+ ратившись к предопределенным функциям (и, следовательно, к другим хранилищам информации, включая базы данных), указывая функции по их URL+адресам и именам и передавая им соответствующие параметры. Это означало бы, что можно создать

XML 353

приложение, теоретически распределенное в Internet (т.е. независимое от того, где расположена программная логика или хранятся данные).

Это именно то, что можно сделать с помощью Web+служб. Вызов функций, написанных другим разработчиком, использование созданных другими программистами баз данных или даже использование множества функций и баз данных в любой точке Internet ++++++ вот для чего предназначены Web+службы. Однако для доступа к Web+службам требуется специ+ альное средство, потому что Web+службы могут работать на разных платформах, ис+ пользовать любые языки и базы данных; кроме того, имеются некоторые проблемы при передаче данных. Здесь полезными оказываются технологии SOAP и WSDL.

SOAP (Simple Object Access Protocol ++++++ простой протокол доступа к объек+ там) ++++++ XML+язык, позволяющий определять для отправки и получения кон+ верт, тело и другие компоненты вызовов Web+служб. Вызовы Web+служб поме+ щаются в SOAP+конверт.

WSDL (Web Service Description Language ++++++ язык описания Web+служб) ++++++ дру+ гой XML+язык, который используется для определения имени, типа и аргумен+ тов, связанных с вызовом Web+службы.

Web+службы являются одним из наиболее важных аспектов применения XML. Су+ ществует множество доступных связанных с Web+службами приложений, которые об+ легчают разработку на PHP как Web+служб, так и обращающегося к этим службам кли+ ентского кода. (Тема Web+служб выходит за рамки данной книги, более подробная информация по этой теме представлена в книге Professional PHP Development.)

PHP и XML

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

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

Далее рассматриваются XML+фукнции, которые были встроены в PHP в течение нескольких последних лет, включая такие нововведения, как расширение simpleXML. Сначала обсуждаются XML+фукнции, которые были встроены в PHP4, затем рассмат+ риваются расширения simpleXML и DOM (Document Object Model ++++++ документная объектная модель) и, наконец, расширения PHP5.

XML-функции в PHP4

PHP5 сохраняет обратную совместимость с многими функциями PHP4, поэтому дан+ ный раздел начинается с обсуждения некоторых XML+фукнций PHP4, после чего рассмат+ риваются новые XML+функции, доступные в PHP5. Функции семейства xml_parser