Отображения xml. Версии XML. Отображение XML во Всемирной паутине

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

Применение стилей CSS ;

Применение XSL ;

Написание на каком-либо языке программирования обработчика XML-документа.

Без использования CSS или XSL XML-документ отображается как простой текст в большинстве веб-браузеров. Некоторые браузеры, такие как Internet Explorer и Mozilla Firefox отображают структуру документа в виде дерева, позволяя сворачивать и разворачивать узлы с помощью нажатий клавиши мыши.

Применение стилей css.

Процесс аналогичен применению CSS к HTML -документу для отображения.

Для применения CSS при отображении в браузере, XML-документ должен содержать специальную ссылку на таблицу стилей. Например:

Это отличается от подхода HTML, где используется элемент .

Применение xsl.

XSL является семейством рекомендаций, описывающих языки преобразования и визуализации XML-документов. Документ трансформируется в формат, подходящий для отображения в браузере. Браузер - это наиболее частое использование XSL , но не стоит забывать, что с помощью XSL можно трансформировать XML в любой формат, например VRML , PDF , текст.

Для задания XSL трансформации (XSLT ) на стороне клиента требуется наличие в XML инструкции следующего вида:

Словари xml

Так как XML является достаточно абстрактным языком, были разработаны словари XML.

Словарь позволяет разработчикам договориться о некотором конечном наборе имен тегов и атрибутов этих тегов. Одним из первых словарей является XHTML , который понимают большинство браузеров. XHTML часто используют для хранения и редактирования контента в CMS .

Были созданы более специализированные словари, например протокол передачи данных SOAP , который не является человеко-ориентированным и достаточно трудно читаем. Есть коммерческие словари, такие как CommerceML , xCBL и cXML которые используются для передачи данных, ориентированных на торговую деятельность, эти словари включают в себя описание системы заказов, поставщиков, продуктов и прочее.

Обычно, описывая какой-либо документ, человек для себя придумывает некоторый словарь, который потом описывается посредством DTD или просто объясняется «на пальцах» заинтересованным лицам.

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

Как выглядит xml-документ?

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

Структура документа

Простейший XML- документ может выглядеть так, как это показано в Примере 1

Первый

Второй подпункт 1

Третий

Последний

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

Тело документа XML состоит из элементов разметки (markup) и непосредственно содержимого документа - данных (content). XML - тэги предназначены для определения элементов документа, их атрибутов и других конструкций языка. Более подробно о типах применяемой в документах разметки мы поговорим чуть позже.

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

Для того, чтобы автоматом преобразовывать содержимое xml-файлов в удобочитаемый вид/формат (html, rtf, pdf, txt, vrml, svg, java и т.д.) - следует воспользоваться XSLT, вместо того, чтобы стараться применить CSS.

Недостатки CSS:
1. CSS не может изменить порядок следования элементов в xml-документе. Если вы захотите отсортировать некоторые элементы или отфильтровать их по некоторому свойству, то CSS вам в этом однозначно не помощник.
2. CSS не выполняет вычисления. Если вы захотите вычислить и вывести значение(например, просуммировать числовые значения всех элементов в xml-документе), CSS вам не подойдёт.
3. CSS не может объединять документы. Если вы захотите объединить пару десятков xml-документов с заказами на покупку и напечатать сводку всех заказанных товаров, то CSS вам опять же не поможет.

Маленький пример использования XSL

Имеется некоторый xml-файл настроек плагина:

Плагин контролирует настройки слоёв чертежей AutoCAD. Ниже представлена таблица, в которой перечислены проверяемые позиции.

Проверка имени слоя
true
Проверка имени слоя на соответствие правилу построения имён

Проверка цвета слоя
true
Проверка на то, чтобы слою назначались цвета из палитры "Index Color"

Проверка типа линии
true
Проверка на то, чтобы слоям назначались типы линий только из определённого набора

Проверка толщин линий
true
Проверка на то, чтобы слоям назначались толщины линий только из определённого набора

Проверка наличия примечания
true
Каждый слой должен иметь примечание, расшифровывающее его назначение

Фиксированный набор слоёв
false
Следует ли запретить пользователям создавать дополнительные слои, по установленным в Стандарте правилам

Плагин должен считывать с него настройки и работать в соответствии с ними. В то же время должна присутствовать некая документация, которую бы юзер мог прочитать и понять. Причём материал, изложенный в документации должен соответствовать тем настройками, которые установлены в текущий момент. Для того, чтобы не держать в голове, что после того, как подправишь настройки, нужно лезть и править документацию, можно всё это представить в виде одного xml-файла. Плагин будет читать из него настройки, а юзер - открывать его в браузере и... видеть его в "человеческом" виде... Для этого создаём файл styleSheet.xsl с таким содержимым:

Настройки плагина

Параметр Значение Примечание

Теперь, если юзер в браузере откроет наш xml-файл, то он увидит не запутанный (с его точки зрения), неудобный xml-текст, а это:

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

Как правильно использовать XML

XML как инструментальное средствоЧасто используемые сокращения

• CDATA: Character Data (символьные данные)
• DOM: Document Object Model (объектная модель документа)
• E4X: ECMAScript for XML (ECMAScript для XML)
• IDE: Integrated Development Environment (интегрированная среда разработки)
• W3C: World Wide Web Consortium (консорциум WWW)
• XML: Extensible Markup Language (расширяемый язык разметки)
• XSLT: Extensible Stylesheet Language Transformations (расширяемый язык преобразований таблиц стилей)

В настоящее время XML воспринимается как нечто само собой разумеющееся. Он повсюду! Но если посмотреть со стороны, то можно увидеть, что это мощная технология. Есть интегрированные среды разработки, которые помогают строить XML-деревья. Есть целый ряд технологий проверки корректности XML-кода. Есть XSLT – специальный язык преобразования XML. Поддержка XML встроена даже непосредственно в синтаксис некоторых языков (как, например, E4X в ActionScript).

Но у XML есть и обратная сторона. Его можно использовать неправильно. Его можно использовать плохо. Он может быть чрезмерно сложным. Он может быть недоопределенным. С ним может быть трудно работать. Что нужно сделать для более эффективного использования этой мощной технологии? В своей статье я дам 10 советов, которые помогут ответить на этот вопрос.

Не используйте XML в качестве имени файла или корневого тега

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

Еще одной проблемой в некоторых XML-документах является использование корневого тега . Это опять-таки ни о чем не говорит. Что находится в этом файле? Если это список контактов, корневым узлом должен быть тег . XML должен быть читабельным, поэтому используйте имена тегов и атрибутов, имеющие отношение к бизнес-задаче, над которой работаете. Если корневым узлом является , я предполагаю увидеть теги , а затем теги , , , и т.д.

Не переопределяйте обобщенные или специфичные для языка конструкции

Я понимаю, что XML – это формат для сохранения данных. В своем большинстве языки предоставляют способ сохранения структур данных в XML. Хорошо, если вы уверены, что только написанные на том же языке процессы будут когда-либо читать или писать ваш XML-код. Такое, однако, встречается редко. Если ваше приложение пишет что-то в файл, вполне вероятно, что в какой-то момент времени его прочтет пользователь или какое-нибудь приложение на другом языке.

Этим я хочу сказать, что специфичные для языка конструкции нужно хранить вне XML. Как часто вы встречали 07-18-2010 ? Что такое NSDate? Ага, это имя класса для работы с датами на прикладной платформе. Что произойдет при смене платформы или языка? Потребуется преобразование тегов NSDate во что-то другое, что используется на новой платформе.

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

Еще одно важное правило – избегайте использования в XML излишних обобщений. Взгляните на следующий пример ():

Листинг 1. Обобщенное дерево узлов jack

Что это означает? Я понял, что это список пользователей. Но человеку трудно это читать и редактировать. Еще хуже то, что этот XML-код очень трудно использовать в средствах, подобных XSLT, или проверять его корректность при помощи схемы. В показано, что на самом деле означает приведенный выше XML-код.

Листинг 2. Более эффективное дерево узлов jack

Разве так не лучше? Код говорит то, что означает, и означает то, что говорит. Его легче читать и анализировать. Его легче проверять и преобразовывать при помощи XSLT. Он даже меньше по размеру.

Не делайте файлы слишком большими

Знаю, что вы скажете: "Дисковая память стоит дешево. За десять центов я куплю еще один терабайт". Это верно. Вы действительно можете создавать гигабайтные XML-файлы. Но программирование – это постоянные компромиссы. Приходится менять дисковое пространство на время или память на время. А при работе с огромным XML-файлом вы получаете худшие стороны и того, и другого. Файл занимает много места на диске, а на его анализ и проверку уходит много времени. Кроме того, большой файл исключает использование DOM-анализатора, поскольку построение дерева требует бесконечного времени и огромного количества памяти.

Какова же альтернатива? Можно создать несколько файлов. Один выступает в качестве индекса, а другие содержат большие ресурсы, которые, возможно, будут нужны не всем пользователям этого XML. Другой вариант– вынос всех больших фрагментов CDATA из XML-файла и помещение их в свои собственные файлы с собственными форматами. Если вы хотите хранить все данные вместе, запакуйте все файлы в новый файл с новым расширением. Любой популярный язык программирования имеет модули, облегчающие быструю упаковку и распаковку файлов.

Не используйте пространства имен, если в этом нет острой необходимости

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

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

Поэтому используйте пространства имен XML, только если это действительно необходимо. Не используйте их просто потому, что "XML позволяет это делать". XML прекрасно работает и без пространств имен.

Не используйте специальные символы

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

Используйте XML Schema

Синтаксический анализ XML является непростой задачей. Для точного анализа необходимо проделать большую работу по защите кода от возможного отсутствия и некорректного использования тегов или атрибутов. Это дополнительная работа по написанию кода, дополнительная сложность, а также затенение реальной бизнес-логики, являющейся вашей главной заботой. Как избежать этого? Проверяйте XML перед его использованием. Для этого можно использовать несколько стандартов. Можно указать Document Type Definition (DTD) или XML Schema (ссылки на информацию о DTD и XML Schema приведены в разделе ). Лично я нахожу XML Schema намного более простой в работе, но если вы новичок в этом деле, попробуйте различные системы проверки корректности.

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

Нумеруйте версии

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

Сочетайте узлы и атрибуты

Инженеры довольно ленивый народ. Я могу это утверждать, поскольку сам такой. Не спорьте, все мы такие. Если интегрированная среда разработки предложит выполнить экспорт XML вместо нас, мы наверняка согласимся. Но обычно интегрированная среда создает очень плохой XML-код. Вероятно, вы уже встречались с чем-то похожим на :

Листинг 3. Список пользователей 1 jack

Должен ли быть тегом? Я утверждаю, что он должен быть атрибутом. Код становится более коротким и осмысленным, появляется возможность искать пользователя по идентификатору при помощи простого XPath-выражения (/users/user[@id=1]).

Чтобы код был читабелен, несомненно лучше использовать атрибуты, как показано в .

Листинг 4. Более удобный список пользователей jack

Понятно, что интегрированная среда сгенерировала , потому что всегда безопаснее использовать узлы. Но атрибуты позволяют идентифицировать важные элементы в DOM-дереве, поэтому следует использовать их.

Используйте CDATA, но не злоупотребляйте этим

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

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

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

Храните необязательные данные в отдельной области

До сих пор я рассказывал об XML-документах с жестким форматом. Я даже рекомендовал использовать технологию проверки корректности, (например, XML Schema), гарантирующую жесткую структуру. Тому есть веская причина: структурированные данные легче анализировать. А если нужна определенная гибкость? Я рекомендую размещать необязательные данные в отдельном блоке в своем собственном узле. Взгляните, например, на .

Листинг 5. Неупорядоченная запись о пользователе jack d herrington 8:00

Эта запись содержит все ожидаемые данные о пользователе. Я согласен с first, middle, last, но зачем здесь runningpace? Это необходимо? Будете ли у вас много таких полей? Будут ли они расширяемыми? Если ответ на все эти вопросы утвердителен, я порекомендовал бы сделать так (см. ):

Листинг 6. Хорошо структурированная запись о пользователе jack d herrington 8:00

При таком подходе вы можете иметь сколько угодно полей, не загромождая пространство имен родительского элемента . Вы даже можете проверить корректность этого документа, а также обратиться к определенному полю при помощи XPath-выражения (//user/userdata/field[@name="runningpace").

Заключение

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

Цель занятия

Знакомство с технологией XML. Изучение возможности представления документов XML в HTML. Использование скриптов JavaScript для навигации по таблице XML и организации поиска данных по условию. Рекомендуемая литература .

Краткие теоретические сведения

Технология XML (eXtensible Markup Language) была создана в конце 90-х годов прошлого столетия. Основные достоинства текста XML:

□ имеет структуру базы данных, доступен ЭВМ и человеку;

□ удобно обрабатывается средствами современных языков программирования;

□ легко переводится в HTML.

Рассмотрим следующий пример текстовой базы данных, написанной на XML:

Three men in the boat

Jerom-K-Jerom

12000

Notre Domme de Paris

V.Hugo

15000

А War and Peace

L.Tolstoy

16500

Angelika - the misstress of ghosts А and S. Gallen

9000

Это пример правильно составленного документа XML, элементами которого являются теги , , , , ,

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

Three men in the boat.

Наберите этот текст в любом редакторе и сохраните его как простой текстовый файл с расширением xml - например, дайте этому файлу имя textbd.xml. Можно просмотреть этот файл браузером Internet Explorer так же, как вы просматривали HTML-файлы. В случае ошибки интерпретатор XML выдаст подробную информацию о дислокации и сути ошибки.

Теперь покажем, как перевести этот вывод в табличную форму HTML, что выполняется средствами HTML. Создадим следующий файл HTML (листинг 2.12).

Листинг 2.12. HTML-документ для отображения таблицы XML

The Book Title

The author

The price

Сохраним этот HTML-файл под именем textbd.html. Теперь откроем его браузером. Результат будет таким (рис. 2.9).

Рис. 2.9. Отображение документа XML в документе HTML

Для подключения созданного ранее XML-файла и связывания его с таблицей используются теги:

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

Тег используется в качестве контейнера. Параметр DATAFLD содержит значение отображаемого элемента XML.

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

Листинг2.13. Модифицированный HTML-документ для отображения таблицы XML

Our first lesson in xml-technology

The Book Title

The author

The price

>

<

Терм > используется для прорисовки стрелки вправо, терм &it - стрелки влево. При этом указываем, что нужно отображать только две записи в таблице:

Теперь создадим для нашего сайта функциональное наполнение. Его смысл будет заключаться в том, что будем вводить название книги целиком или какие-то его фрагменты, и по нажатию кнопки система должна выдавать другие реквизиты книги: автора и цену либо сообщать, что книга не найдена. Теперь понадобится привлечь JavaScript. Собственно потребуется всего несколько команд.

□ getElementByTagName("title").item(i).text;

Эта команда возвращает значение элемента из XML-файла, который является i-м по порядку перечисления этих элементов .

□ getElementsByTagName("title").length;

Эта команда возвращает общее число элементов из ХМ L-документа.

□ String.indexOf(stringl);

Эта команда возвращает позицию, с которой строка stringi входит в строку string либо -i, если вхождений нет.

Теперь приведем расширенный HTML-код для этой задачи (листинг 2.14).

Листинг2.14. Расширенный HTML-документ для отображения таблицы XML

function showelement()

// Подключение XML-документа:

var odoc=new ActiveXObject("Microsoft.XMLDOM");

odoc.async=false; // Приостановка программы,

// пока загрузка не завершится odoc.load("textbd.xml"); // Загрузка XML-документа в память var stringl=document.myform.mytext.value; z=odoc.getElementsByTagName("title").length;// Получение

// длины элемента // с тегом //

for(i=0;i