GetInfo.Ru – Компьютерная библиотека
Последние поступления
Как выбрать систему управления базы данных
Базы данных03/09/14
Этапы загрузки UNIX (в схеме)
Unix27/03/12
Gatewall Antispam: тотальный контроль электронной почты
Спам21/04/11
Мастер-класс: создаем Интернет-магазин (Часть 1)
Обзоры ПО20/04/11
CorelDRAW Graphics Suite X5: Что нового?
Обзоры ПО20/07/10
Добавить статью
Самые читаемые материалы
DOM для Web-сервисов, часть 1(11687)
XML-формат обмена данными Сбалансированной системы показателей: практический пример (часть II)(10382)
XML и базы данных? Доверьтесь своей интуиции(10315)
XML Viewer (IBM alphaWorks)(9522)
Обзор XML-стандартов, часть 2(9229)
Всего статей: 793Всего авторов: 364Подразделов: 47Добавлено за сутки: 0
Статьи  СТАТЬИ Форум  ФОРУМ Рейтинг  РЕЙТИНГ Поиск  ПОИСК Контакты  КОНТАКТЫ
» Главная » XML » Канонизация XML (Часть 2)

Канонизация XML (Часть 2)


Intersoft Lab
market@iso.ru
http://www.iso.ru/

В предыдущей статье, посвященной Рекомендации W3C "Канонический XML" (Canonical XML), рассказывалось, почему и когда необходимо канонизировать XML-файлы. Кроме того, в ней последовательно - шаг за шагом - был показан процесс получения канонической формы XML-документа.

Во второй и завершающей статье данного цикла мы продолжим изучение этой концепции и рассмотрим требования, предъявляемые к разделам CDATA, инструкциям обработки (processing instruction), комментариям, ссылкам на внешние сущности (external entity) и подмножествам XML-документов.

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

14. Разделы CDATA
Каноническая форма требует, чтобы все разделы CDATA были заменены своим эквивалентным XML-содержимым PCDATA. Именно это и сделано в Листинге 2. Если вы сравните эти два листинга, то обнаружите, что разметка для раздела CDATA ("<![CDATA[" в начале и "]]>" в конце) была удалена, а вместо символа "<" в разделе CDATA Листинга 1 в Листинге 2 была добавлена эквивалентная управляющая последовательность (&lt;).

15. Инструкции обработки
Согласно этому требованию, необходимо нормализовать свободные места внутри инструкций обработки. Это означает, что все свободное место между объектом (target) и его данными должно быть сокращено до единственного пробела (символ #x20).

В XML-файле Листинга 2 присутствует только одна инструкция обработки. Объект в этой инструкции - xml-stylesheet, за которым следует строка данных. Листинг 3 отличается от Листинга 2 только тем, что все свободное место между объектом и его данными было нормализовано.

16. Ссылки на внешние сущности
Вспомните соответствующий раздел первой статьи, в котором было показано, как канонизировать ссылки на разобранные внутренние сущности. Аналогичным образом ссылки на разобранные внешние сущности заменяются содержимым, на которое они ссылаются (см. Листинг 4).

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

Например, в Листинге 5 удалены комментарии, присутствующие в Листинге 4 (каноническая форма без комментариев).

Теперь к Листингу 5 можно применить все тринадцать операций (описанных в первой статье). Результат этого процесса приведен в Листинге 6.

18. Подмножества документов
Подмножества или фрагменты (части целых XML-файлов) XML-документов представляют очень интересный случай. Когда мы извлекаем из XML-файла некоторую его часть, мы неизбежно отделяем узел потомок (child node) от его родителя (назовем его "осиротевший" узел [orphan node]). Это отделение может привести к недопустимости контекста пространства имен потомка, если контекст пространства имен "осиротевшего" потомка был объявлен в родителе, который не был включен в подмножество документа.

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

Единственное различие между спецификациями "Канонический XML" и "Исключающая канонизация XML" состоит в том, что предшествующий контекст (ancestor context) либо сохраняется, либо удаляется.

Сохранение предшествующего контекста
Рассмотрим Листинг 7, который является сообщением SOAP. Предположим, что нам необходимо канонизировать элемент booking, значение атрибута unitCharge которого равно 50. Первым шагом будет написание выражения XPath, которое будет извлекать требуемый фрагмент документа из XML-файла:


    (//. | //@* | //namespace::*)[ancestor-or-self::booking[@unitCharge="50"]]

Приведенное выражение XPath извлечет требуемый элемент из XML-файла, представленного в Листинг 7. Часть выражения, заключенная в первые скобки (//. | //@* | //namespace::*), отбирает все элементы, атрибуты и узлы пространств имен XML-файла. Выражение во внешних квадратных скобках (ancestor-or-self::booking) выбирает все элементы booking (вместе с их потомками); часть выражения, заключенная во внутренние квадратные скобки (@unitCharge="50"), отбирает элемент booking, значение атрибута unitCharge которого равно 50.

Листинг 8 является подмножеством Листинга 7 и включает элемент booking. Возможно, часть читателей испытает искушение попробовать канонизировать Листинг 8, применив к нему последовательность из тринадцати шагов, описанных в первой статье. Однако, прежде чем сделать это, необходимо выполнить дополнительную обработку, чтобы устранить пару проблем:

  1. Объявления пространств имен для префиксов bs и hs были выполнены в родительском теге (элемента booking), который не вошел в подмножество документа Листинга 8.
  2. В Листинге 7 атрибут xml:lang элемента bookingPackage применим для всех своих потомков. Этот атрибут также отсутствует в подмножестве документа Листинга 8.

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

  1. Объявления пространств имен в пропущенных предках подмножеств документов должны быть включены в каноническую форму.
  2. Атрибуты в пространстве имен также включаются в каноническую форму, если только они уже не присутствуют в канонизируемом фрагменте.

Эти два положения предназначены для сохранения предшествующего контекста подмножества документа. Так, в Листинг 9 вошли четыре объявления пространств имен, выполненых в предках элемента booking в Листинге 7. Листинг 9 также содержит атрибут xml:lang. Обратите внимание, что каноническая форма подмножества документа не включает ни одного символа перевода строки (#xA), то есть весь файл - это одна строка.

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

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

Упаковка данных в конверт
Технология SOAP стремительно превращается в фактический стандарт передачи XML-сообщений через Интернет. SOAP определяет формат для заключения XML-данных в конверты.

В Листинге 7 элемент PackageBooking "завернут" внутри элемента SOAP:Body. Листинг 7 демонстрирует простой механизм упаковки данных в конверт, при котором полезная нагрузка сообщения (то есть сообщение, которое необходимо отправить через Интернет) заворачивается в элемент SOAP:Body, а сам элемент SOAP:Body целиком заключается в элемент SOAP:Envelope.

Преимущество такой простой упаковки данных состоит в том, что она позволяют активировать вертикальное вложение (vertical stacking) протоколов, основанных на XML. Вертикальное вложение означает, что для определенных низкоуровневых задач (таких как подписание, шифрование, маршрутизация и так далее) могут быть определены протоколы и форматы сообщения; уровни более высоких протоколов будут использовать сервис, предлагаемый более низкими уровнями. Например, WS-Security, высокоуровневый протокол безопасности XML, разрабатываемый Техническим комитетом консорциума OASIS, использует протокол SOAP для реализации механизмов подписи и шифрования, поддерживаемых спецификациями консорциума W3C "Электронная подпись XML" (XML Digital Signature) и "Шифрование XML" (XML Encryption), соответственно.

Помимо элемента SOAP:Body Листинг 7 также включает элемент SOAP:Header. Этот элемент SOAP:Header является необязательным и предназначен для информации, касающейся протокола. Это фактически означает, что полезная нагрузка сообщения находится внутри элементов SOAP:Body, а заголовки протокола располагаются в элементе SOAP:Header. Например, WS-Security использует SOAP Header, чтобы упаковать информацию о подписи.

Управление конвертом
Приложение, которое получит SOAP-сообщение, вероятно, "разорвет" конверт (обертку) и извлечет полезную нагрузку XML (XML-сообщение), чтобы обработать полученное сообщение. Этот разрыв конверта SOAP и извлечение полезной нагрузки XML называется распечатывание конверта (de-enveloping). Кроме того, получающему приложению, возможно, потребуется заново упаковать в конверт (re-envelope) XML-сообщение, полученное в новом конверте.

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

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

Разумеется, это XML-сообщение будет составлено каким-нибудь поддерживающим XML и SOAP клиентским приложением, которое запишет и упакует всю информацию внутри конверта SOAP - клиент же при этом может даже и не подозревать о существовании XML и SOAP.

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

Подобным образом при получении ответа из этих отелей и бюро проката Web-служба заново упакует в конверт полученную информацию, а затем отошлет этот новый конверт своему клиенту.

Исключающая канонизация XML
Перейдем теперь к рассмотрению Листинга 10, который является SOAP-сообщением, полученным из вымышленного отеля в ответ на запрос от Web-службы туроператора.

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

Листинг 7 фактически является тем вариантом тура, который будет отправлен клиенту туристической компании. Первый элемент booking в Листинге 7 (значение атрибута unitCharge которого равно 50 и который мы, канонизировав, преобразовали в Листинг 9) точно такой же , как элемент booking в Листинге 10.

Чтобы показать значимость канонизации с точки зрения применения в объединенных Web-службах, давайте предположим, что, отправляя SOAP-сообщение туроператору, работники отеля решат подписать элемент booking в Листинге 10 с тем, чтобы турист мог убедиться, что процесс резервирования номера в гостинице (booking) действительно имеет место.

В Листинге 11 приведена каноническая форма элемента booking Листинга 10. Это та каноническая форма, которой воспользуются работники отеля для того, чтобы создать профиль сообщения. С другой стороны, вспомните о том, что Листинг 9 являлся канонической формой того же элемента booking, когда он был частью Листинга 7. Вот почему клиент турфирмы воспользуется Листингом 9, чтобы проверить профиль сообщения, полученный из отеля.

Если вы сравните Листинги 11 и 9 , вы заметите, что они отличаются друг от друга. Причина этого различия заключается в том, что, канонизируя один и тот же элемент booking, мы сохранили предшествующий контекст из двух различных XML-документов.

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

Исключающая канонизация применяется только при канонизации фрагментов XML-файлов; ниже приведены ее основных отличия от рекомендации "Канонический XML":

  1. Атрибуты из пространства имен не импортируются из предков в "сиротские узлы".
  2. Пропущенные объявления пространств имен включается в исключающей канонической форме в элемент только в том случае если:
    • объявление пространства имен используется этим элементом или любыми атрибутами или атрибутами его потомков;
    • объявление пространства имен уже используется в исключающей канонической форме.

Обратите внимание на то, что второе правило относится также и к объявлениям пустых используемых по умолчанию пространств имен (xmlns=""). Это означает, что исключающая каноническая форма элемента будет включать объявления xmlns="", если этот элемент принадлежит к пустому используемому по умолчанию пространству имен, а в объявлении используемого по умолчанию пространства имен для ближайшего предшественника в исключающей канонической форме присутствует непустое используемое по умолчанию пространство имен (xmlns="http://someURI...").

Применив эти правила к элементу Листинга 10, можно получить исключающую каноническую форму, представленную в Листинге 12. Обратите внимание на то, что исключающая каноническая форма первого элемента Листинга 7 (значение атрибута unitCharge равно 50) точно такая же, как в Листинге 12.

Неразрешенные сценарии
Следует заметить, что использование спецификации "Канонический XML" может привести к возникновению следующих двух проблем:

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

Ресурсы

  • Познакомьтесь с первой статьей.
  • Официальная спецификация Exclusive XML Canonicalization доступна на сайте консорциума W3C.
  • В этой статье упоминалось о SOAP и WS-Security. Кто интересуется этими вопросами, может скачать и прочитать официальные спецификации, чтобы понять, как WS-Security Электронную подпись XML упаковывает в заголовки SOAP.
  • На этой странице приведены ссылки на некоторые реализации спецификации "Канонический XML"
  • В статье "Используя XPath для беспроводных устройств" (Implementing XPath for Wireless Devices), написанной Билал Сиддикуи, рассказывается о синтаксисе XPath и о том, как его можно использовать этот язык.
Оригинальный текст статьи можно посмотреть здесь:
XML Canonicalization, Part 2

 
17.02.2003
Версия для печати Версия для печати Запомнить ссылку Запомнить ссылку
Ваша оценка:  1   2   3   4   5     

 О проектеПерепечаткаАвторамПартнерыО нас пишут
Наверх
©2003—2007. GETINFO.RU. ВСЕ ПРАВА ЗАЩИЩЕНЫ.