ГЛАВА 14. РНР и XML
Определение типа документа(DTD)
DTD представляет собой совокупность синтаксических правил, на основе которых проверяется структура документа XML. В DTD явно определяется структура документа XML, указываются элементы и их атрибуты, а также приводится другая информация, распространяющаяся на все документы XML, созданные на основе данного DTD.
Учтите, что наличие DTD не является обязательным. Если DTD существует, система XML руководствуется им при интерпретации документа XML. Если DTD отсутствует, предполагается, что система XML должна интерпретировать документ по собственным правилам. Впрочем, для документов XML все же рекомендуется создавать DTD, поскольку это упрощает их интерпретацию и проверку структуры.
DTD можно включить непосредственно в документ XML, сослаться на него по URL или использовать комбинацию этих двух способов. При непосредственном включении DTD в документ XML определение DTD располагается сразу же после пролога:
<!DOCTYPE имя_корневого_элемента [ ;
...прочие объявления...
] >
Атрибут имя_корневого_элемента соответствует имени корневого элемента в тегах, содержащих весь документ XML. В секции «прочих объявлений» находятся определения элементов, атрибутов и т. д.
Возможно, вы предпочитаете разместить DTD в отдельном файле, чтобы обеспечить модульную структуру программы. Давайте посмотрим, как выглядит ссылка на внешний DTD в документе XML. Задача решается одной простой командой:
<!DOCTYPE имя_корневого_элемента SYSTEM "some_dtd.dtd">
Как и в случае с внутренним объявлением DTD, имя_корневого_элемента должно соответствовать имени корневого элемента в тегах, содержащих весь документ XML. Атрибут SYSTEM указывает на то, что some_dtd.dtd находится на локальном сервере. Впрочем, на файл some_dtd.dtd также можно сослаться по его абсолютному URL. Наконец, в кавычках указывается URL внешнего DTD, расположенного на локальном или на удаленном сервере.
Как же создать DTD для листинга 14.1? Во-первых, мы собираемся создать в документе XML ссылку на внешний DTD. Как упоминалось в предыдущем разделе, ссылка на DTD выглядит так:
<!DOCTYPE cookbook SYSTEM "cookbook.dtd">
Возвращаясь к листингу 14.1, мы видим, что cookbook является именем корневого элемента, a cookbook.dtd — именем DTD-файла. Содержимое DTD показано в листинге 14.2, а ниже приведены подробные описания всех строк.
Листинг 14.2. DTD для листинга 14.1(cookbook.dtd)
<?xml version="1.0"?>
<!DOCTYPE cookbook [
<!ELEMENT cookbook(recipe+)>
<!ELEMENT recipe(title, description, ingredients, process)>
<!ELEMENT title(#PCDATA)>
<!ELEMENT description(#PCDATA)>
<!ELEMENT ingredients(ingredient+)>
<!ELEMENT ingredient(#PCDATA)>
<!ELEMENT process Cstep+)>
<!ELEMENT step(#PCDATA)>
<!ATTLIST recipe category CDATA #REQUIRED>
] >
Что же означает этот загадочный документ? Несмотря на внешнюю сложность, в действительности он довольно прост. Давайте переберем все содержимое листинга 14.2:
<?xml version="1.0"?>
Перед нами пролог XML, о котором уже говорилось выше.
<!DOCTYPE cookbook [
Вторая строка сообщает, что далее следует DTD с именем cookbook.
<!ELEMENT cookbook(recipe+)>
Третья строка описывает элемент XML, в данном случае — корневой элемент cookbook. После него следует слово recipe, заключенное в круглые скобки. Это означает, что в теги cookbook заключается вложенный тег с именем recipe. Знак + говорит о том, что в родительских тегах cookbook находится одна или несколько пар тегов recipe.
<!ELEMENT recipe(title, description, ingredients. process)>
Четвертая строка описывает тег recipe. В ней сообщается, что в тег recipe входят четыре вложенных тега: title, description, ingredients и process. Поскольку после имен тегов не указываются признаки повторения(см. следующий раздел), внутри тегов recipe должна быть заключена ровно одна пара каждого из перечисленных тегов.
<! ELEMENT title(#PCDATA)>
Перед нами первое определение тега, который не содержит вложенных тегов. В соответствии с определением он содержит #PCDATA, то есть произвольные символьные данные, не считающиеся частью разметки.
<!ELEMENT ingredients(ingredient+)>
В соответствии с определением элемент ingredients содержит один или несколько тегов с именем ingredient. Обратитесь к листингу 14.1, и вы все поймете.
<! ELEMENT ingredient(#PCDATA)>
Поскольку элемент ingredient соответствует отдельному ингредиенту, вполне логично, что этот элемент содержит простые символьные данные.
<! ELEMENT process(step+)>
Элемент process содержит один или несколько экземпляров элемента step.
<! ELEMENT step(#PCDATA)>
Элемент step, как и элемент ingredient, соответствует отдельному пункту в списке более высокого уровня. Следовательно, он должен содержать символьные данные.
<!ATTLIST recipe category CDATA #REQUIRED>
Обратите внимание: элемент recipe в листинге 14.1 содержит атрибут. Этот атрибут, category, определяет общую категорию, к которой относится рецепт — в приведенном примере это категория «итальянская кухня»(Italian). В определении ATTLIST указывается как имя элемента, так и имя атрибута. Кроме того, отнесение каждого рецепта к определенной категории упрощает классификацию, поэтому атрибут объявляется обязательным(#REQUIRED).
]>
Последняя строка просто завершает определение DTD. Определение всегда должно быть должным образом завершено, иначе произойдет ошибка.
В завершение этого раздела я приведу сводку основных компонентов типичного DTD-файла:
- объявления типов элементов;
- объявления атрибутов;
- ID, IDREF и IDREFS;
- объявления сущностей.
Некоторые из этих компонентов уже встречались нам в описании листинга 14.2. Далее каждый компонент будет описан более подробно.
Объявления элементов
Все элементы, используемые в документе XML, должны быть определены в DTD, прилагаемом к документу. Мы уже встречались с двумя распространенными разновидностями определений: для элемента, содержащего другие элементы, и элемента, содержащего символьные данные. Данное определение свидетельствует, что элемент содержит только символьные данные:
<! ELEMENT описание(#РСDАТА)>
Следующее определение элемента process говорит о том, что он содержит ровно один вложенный элемент с именем step:
<!ELEMENT process(step)>
Впрочем, процессы(process) из одного шага(step) встречаются довольно редко — скорее всего, шагов будет несколько. Чтобы указать, что элемент содержит один или несколько экземпляров вложенного элемента step, следует воспользоваться признаком повторения:
<!ELEMENT process(step+)>
Количество вложенных элементов можно задать несколькими способами. Полный список операторов элементов приведен в табл. 14.1.
Таблица 14.1. Операторы элементов
Признак |
Значение |
? |
Ноль или ровно один экземпляр |
* |
Ноль или несколько экземпляров |
+ |
Один или несколько экземпляров |
|
Ровно один экземпляр |
| |
Один из элементов |
, |
Перечисление элементов |
Если элемент будет содержать несколько вложенных элементов, их следует перечислить через запятую в определении родительского элемента:
<!ELEMENT recipe(title, description, ingredients, process)>
Поскольку признаки повторения не указаны, каждый тег должен встречаться ровно один раз.
Определение элемента уточняется при помощи логических операторов. Предположим, вы работаете с рецептами, в которые всегда входят макароны(pasta) с одним или несколькими типами сыра(cheese) или мяса(meat). В этом случае элемент ingredient определяется следующим образом:
<!ELEMENT ingredient(pasta+,(cheese | meat)+)>
Поскольку элемент pasta обязательно должен присутствовать в элементе ingredient, он указывается с признаком повторения +. Затем следует либо элемент cheese, либо элемент meat; мы разделяем альтернативы вертикальной чертой и заключаем их в круглые скобки со знаком +, поскольку в рецепт всегда входит либо одно, либо другое.
Существуют и другие разновидности определений элементов. Мы рассмотрели лишь простейшие случаи. Тем не менее, приведенного материала вполне достаточно для понимания примеров, приведенных в оставшейся части этой главы.
Объявления атрибутов
Атрибуты элементов описывают значения, связываемые с элементами. Элементы XML, как и элементы HTML, могут иметь ноль, один или несколько атрибутов. Общий синтаксис объявления атрибутов выглядит следующим образом:
<!ATTLIST имя_элемента имя_атри6ута1 тип_данных1 флаг1
Имя_элемента определяет имя элемента, включаемое в тег. Затем перечисляются атрибуты, связанные с данным элементом. Объявление каждого атрибута состоит из трех основных компонентов: имени, типа данных и флага, определяющего особенности данного атрибута. Вместо многоточия(...) могут быть расположены объявления других атрибутов.
Простое объявление атрибута уже встречалось нам в листинге 14.2:
<!ATTLIST recipe category CDATA #REQUIRED>
Тем не менее, как видно из приведенного общего определения, допускается одновременное объявление нескольких атрибутов. Допустим, в дополнение к атрибуту category вы хотите связать с элементом recipe дополнительный атрибут difficulty(сложность приготовления). Оба атрибута объявляются в одном списке:
<!ATTLIST recipe category CDATA #REQUIRED difficulty CDATA #REQUIRED>
Форматировать объявления подобным образом необязательно; тем не менее, многострочные объявления нагляднее однострочных. Кроме того, поскольку оба атрибута являются обязательными, тег reci ре не может ограничиться каким-нибудь одним атрибутом, он должен включать в себя оба атрибута сразу. Например, следующий тег будет считаться неверным: <recipe difficulty="hard">
Почему? Потому что в нем отсутствует атрибут category. Правильный тег должен содержать оба атрибута:
<recipe category="Italian" difficulty="hard">
Особые условия обработки атрибута описываются тремя флагами, перечисленными в табл. 14.2.
Таблица 14.2. Флаги атрибутов
Флаг |
Описание |
#FIXED |
Во всех экземплярах элемента в документе атрибуту может присваиваться только одно конкретное значение |
#IMPLIED |
Если атрибут не указан в элементе, используется значение по умолчанию |
#REQUIRED |
Атрибут является обязательным и должен присутствовать во всех экземплярах элемента в документе |
Типы атрибутов
Атрибут элемента может объявляться с определенным типом. Типы атрибутов описаны далее.
Атрибуты CDATA
Очень часто атрибуты содержат общие символьные данные. Такие атрибуты называются атрибутами CDATA. Следующий пример уже встречался в начале этого раздела:
<!ATTLIST recipe category COATA #REQUIRED>
Атрибуты ID, IDREF и IDREFS
Идея однозначного представления данных(например, информации о пользователе или товаре, хранящейся в базе данных) посредством идентификаторов неоднократно встречалась в предыдущих главах книги. Идентификаторы также часто используются в XML, поскольку перекрестные ссылки между документами применяются не только в общих задачах обработки данных, но и в World Wide Web(гиперссылки).
Идентификаторы элементов присваиваются атрибуту ID. Допустим, вы хотите связать с каждым рецептом уникальный идентификатор. Соответствующий фрагмент DTD может выглядеть так:
<!ELEMENT recipe(title, description, ingredients, process)>
<!ATTLIST recipe recipe-id ID #REQUIRED>
<!ELEMENT recipe-ref EMPTY>
<!ATTLIST recipe-ref go IDREF #REQUIRED>
После этого объявление элемента recipe в документе может выглядеть так:
<recipe recipe-id="ital003">
<title>Spaghetti alla Carbonara</title>
Рецепт однозначно определяется идентификатором ital003. Следует помнить, что атрибут redpe-id относится к типу ID, поэтому ital003 не может использоваться в качестве значения атрибута recipe-id другого элемента, в противном случае документ будет считаться синтаксически неверным. Теперь допустим, что позднее вы захотели сослаться на этот рецепт из другого документа — скажем, из списка любимых рецептов пользователя. Именно здесь в игру вступают перекрестные ссылки и атрибут IDREF. Атрибуту IDREF присваивается идентификатор, используемый для ссылок на элемент, — по аналогии с тем, как URL используется для идентификации страницы в гиперссылке. Рассмотрим следующий фрагмент кода XML:
<favoriteRecipes>
<recipe-ref go="ital003">
</favoriteRecipes>
В процессе обработки документа XML элемент заменяется более наглядной ссылкой на рецепт с указанным идентификатором(например, названием рецепта). Вероятно, он будет отформатирован в виде гиперссылки, чтобы упростить переход к указанному рецепту.
Перечисляемые атрибуты
При объявлении атрибута можно перечислить все допустимые значения, принимаемые атрибутом. В нашем примере это было бы удобно, поскольку вы можете сразу определить список допустимых категорий. Приведенное выше объявление записывается в следующем виде:
<!ATTLIST recipe category(Italian | French | Japanese | Chinese)
#REQUIRED difficulty(easy | medium | hard) #REQUIRED)
Обратите внимание: при использовании списков допустимых значений включать в объявление тип CDATA не нужно, поскольку все перечисленные значения относятся к формату CDATA.
Перечисляемые атрибуты со значением по умолчанию
Иногда бывает удобно объявить для атрибута значение по умолчанию. Скорее всего, вам уже приходилось делать это раньше при построении форм с раскрывающимися списками. Например, если большинство рецептов в вашей поваренной книге относится к итальянской кухне, атрибут recipe будет часто относиться к категории Italian. В этом случае категорию Italian можно назначить по умолчанию:
<!ATTLIST recipe category(Italian | French | Japanese | Chinese)
"Itaian">
Если атрибут category не задан явно, по умолчанию ему присваивается значение Italian.
Атрибуты ENTITY и ENTITIES
Данные в документах XML не всегда являются текстовыми — документ может содержать и двоичную информацию(например, графику). На такие данные можно ссылаться при помощи атрибута entity. Например, в описании элемента description можно указать атрибут recipePicture с графическим изображением:
<!ATTLIST description recipePicture ENTITY #IMPLIED>
Также можно объявить сразу несколько сущностей, заменив ENTITY на ENTITIES. Значения разделяются пробелами.
Атрибуты NMTOKEN и NMTOKENS
Атрибуты NMTOKEN представляют собой строки из символов, входящих в ограниченный набор. Объявление атрибута с типом NMTOKEN предполагает, что значение атрибута соответствует установленным ограничениям. Как правило, значение атрибута NMTOKEN состоит из одного слова:
<!ATTLIST recipe category NMTOKEN #REQUIRED>
Можно объявить сразу несколько атрибутов, заменив NMTOKEN на NMTOKENS. Значения разделяются пробелами.
Объявления сущностей
Объявление сущности напоминает команду define в некоторых языках программирования, включая РНР. Ссылки на сущности кратко упоминались в предыдущем разделе «Знакомство с синтаксисом XML». На всякий случай напомню, что ссылка на сущность используется в качестве замены для другого фрагмента содержания. В процессе обработки документа XML все вхождения сущности заменяются содержанием, которое она представляет. Существует два вида сущностей: внутренние и внешние.
Внутренние сущности
Внутренние сущности напоминают строковые переменные, связывающие имя с фрагментом текста. Например, если вы хотите определить имя для ссылки на информацию об авторских правах, можно объявить сущность следующего вида:
<!ENTITY Copyright "Copyright 2000 YourCompanyName. All Rights Reserved.">
В процессе обработки документа все экземпляры &Соруright заменяются текстом «Copyright 2000 YourCompanyName. All Rights Reserved». Весь код XML в заменяющем тексте обрабатывается так, словно он присутствовал в исходном документе.
Внутренние сущности удобны в ситуациях, когда вы планируете использовать сущность в относительно небольшом количестве документов XML. При большом количестве документов лучше воспользоваться внешними сущностями.
Внешние сущности
Внешние сущности используются для ссылок на содержание, находящееся в другом файле. Сущности этого типа могут содержать текстовую информацию, но также могут ссылаться и на двоичные данные(например, графику). Возвращаясь к предыдущему примеру, допустим, что вы решили сохранить информацию об авторских правах в отдельном файле, чтобы упростить ее редактирование в будущем. Ссылка на созданный файл выглядит следующим образом:
<!ENTITY Copyright SYSTEM "http://yoursite.com/administer/copyright.xml">
При последующей обработке документа XML все ссылки &Соруright заменяются содержимым документа copyright.xml. Весь код XML в заменяющем тексте обрабатывается так, словно он присутствовал в исходном документе.
Внешние сущности также удобно использовать для ссылок на графические изображения. Например, если вы хотите включить в документ XML графический логотип, создайте внешнюю сущность:
<!ENTITY food_picture SYSTEM http://yoursite.com/food/logo.gif>
Как и в предыдущем примере, все ссылки &food_picture заменяются графическим изображением, на которое указывает ссылка. Поскольку данные являются двоичными, а не текстовыми, они не интерпретируются.
Ресурсы, посвященные XML
Хотя приведенного выше материала вполне достаточно для понимания базовой структуры документов XML, данное описание не является полным. Ниже приведены ссылки на ресурсы Интернета, содержащие более подробную информацию:
В оставшейся части главы рассказано о том, как использовать РНР для обработки документов XML. На первый взгляд задача кажется очень сложной(лексический анализ любых документов любого типа вызывает немало затруднений).
Но стоит познакомиться с базовой стратегией работы с XML в РНР, и все оказывается на удивление просто.
Назад |
Содержание раздела |
Общее Содержание |
Вперед
Если Вы не нашли что искали, то рекомендую воспользоваться поиском по сайту:
|