XML требователен Несмотря на гибкость



XML требователен

Несмотря на гибкость, XML порой более требователен, чем HTML. В нем существуют правила, которым должны подчиняться данные. Довольно сжато они описаны в спецификации XML, которую можно найти на http://www.w3.org/TR/1998/REC-xml-19980210. Я советую обратиться к какой-либо из аннотированных версий, подобных версии Тима Брея (Tim Bray) с http://www.xml.com или книге Роберта Дюшарма (Robert Ducharme) «XML: The Annotated Specification» (XML: Аннотированная спецификация) (Prentice Hall), вместо того чтобы изучать официальную спецификацию. Первая свободно доступна в «онлайне», а во второй приведено много примеров XML-кода.

Вот два правила XML, которые заставляют спотыкаться тех, кто знаком с HTML:

1. Все, что начато, должно быть закончено. В приведенном выше примере список для машины начинался с <inachi nc>, а завершался с использованием </machine>. Без закрывающего тега это был бы пример XML, содержащий ошибку.

В HTML такие теги, как <img src="picture. ]pg">, вполне могут не иметь закрывающего тега. Но в XML это неверно, поэтому его нужно переписать либо так:

<img src="picture.jpg"> </img>

либо так:

<img src="picture.jpg" />

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

2. Открывающие и закрывающие теги должны в точности соответствовать друг другу. Нельзя изменять их регистр. Если используется открывающий тег <MaChINe>, то закрывающим должен быть </MaChINo -, но не </МАСН> и не тег с любой другой комбинацией регистров. В этом отношении HTML гораздо более снисходителен.

Это два основных правила из спецификации XML. Но иногда автор определяет собственные правила, которым должен подчиняться анализатор XML. Под «подчиняться» следует подразумевать «выдавать предупреждения» или «останавливать анализ» при чтении XML-данных.
Если использовать в качестве примера предыдущее определение машины в базе данных, то можно ввести дополнительное правило: «Все элементы <nac:ine> должны содержать элементы <папе> и <ipaco'"bss--». Можно также ограничить содержимое элемента определенными значениями, подобными «YES» или «NO».

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

В текущей спецификации XML используется DTD (Document Type Definition, определение типа документа), основа SGML. Вот небольшой пример кода из спецификации XML, в котором определение типа находится в начале самого документа:

<?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE greeting [

<!ELEMENT greeting (SPCDATA)>

]>

<greeting>Hello. world!</greeting>

В первой строке примера задается версия XML и применяемая кодировка для документа (в данном случае это Unicode). Следующие три строки определяют типы данных из этого документа. В последней строке приводится сам документ (элемент <greeting>).



При желании определить способ, с помощью которого подтверждалась бы правильность кода <machine> в первом примере из начала приложения, следовало бы добавить в начало файла нечто подобное:

<?xml version="1.О" encoding="UTF-8" ?> <!DOCTYPE machines [

<!ELEMENT machine (name,department, room,owner,ipaddress)>

<!ELEMENT name (#PCDATA)>

<!ELEMENT department (#PCDATA)>

<!ELEMENT room (#PCDATA)>

<!ELEMENT owner (#PCDATA)>

<!ELEMENT ipaddress (#PCDATA)> ]>

Это определение требует, чтобы данные, соответствующие машине, состояли бы из элементов name, department, room, owner и ipaddress (именно в таком порядке). Каждый из этих элементов описывается как PCDATA (см. раздел «Пережитки» в конце данного приложения).

В другом популярном предложении, которое пока не является спецификацией, рекомендовано в DTD-подобных целях использовать описания данных под названием схемы (schemas). Сами схемы пишутся на XML. Вот пример кода схемы, использующей реализацию от Microsoft с http://www.w3.org/TR/1998/ NOTE-XML-data/:

<9XML version '1.0 ?> <schema id= 1Mac"i"eSchlea'

x'iHrs="i;r"r' schemtis-niicrcsof!

<!-определяем типы элементов (з;.:е они являются просто строками/PCDATA)

<strng/> </elementType> <elementType id="departnie'iT" .>

<str:ng/-' </'eleraentType> <elementType id="room">

<stnng/> </'elementType> <elenientType id="owner">

<string,/> </elementType> <elementType id="ipaddress">

<string/> </elementType>

<!-определяем сам элемент -->

<elementType id="Machine" content="CLOSED">

<element type="#name" occurs="REQUIRED"/>

<element type="#department" occurs="REQUIRED"/>

<element type="#room" occurs="REQUIRED"/>

<element type="»owner" occurs="REQUIRED"/>

<element type="#ipaddress" occurs="REQUIRED"/> </elementType> </schema>

Технология схем XML до сих пор (на момент написания книги) находится в стадии обсуждения. XML-данные, которые использовались в приведенном выше примере, являются всего лишь одним из предложений, рассматриваемым группой Working Group. Поскольку эта технология очень быстро развивается, я советую следить за текущими стандартами (их можно найти на http://www.w3.org) и за тем, насколько совместимо с ними ваше программное обеспечение.

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



Содержание раздела