| ||||||||||||||||
 | ||||||||||||||||
| ||||||||||||||||
 | ||||||||||||||||
| ||||||||||||||||
|
|
Канонизация XML (Часть 2) В предыдущей статье, посвященной Рекомендации W3C "Канонический XML" (Canonical XML), рассказывалось, почему и когда необходимо канонизировать XML-файлы. Кроме того, в ней последовательно - шаг за шагом - был показан процесс получения канонической формы XML-документа. Во второй и завершающей статье данного цикла мы продолжим изучение этой концепции и рассмотрим требования, предъявляемые к разделам CDATA, инструкциям обработки (processing instruction), комментариям, ссылкам на внешние сущности (external entity) и подмножествам XML-документов. Начнем с примера. Листинг 1 является XML-файлом, который содержит, помимо всего прочего, раздел CDATA, комментарии, инструкцию по обработке и ссылку на внешнюю сущность. Тринадцати шагов канонизации, о которых шла речь в первой статье, уже недостаточно для того, чтобы канонизировать этот документ. Нам потребуется выполнить еще несколько дополнительных действий. Листинг 1 <?xml version="1.0"?> 14. Разделы CDATAКаноническая форма требует, чтобы все разделы CDATA были заменены своим эквивалентным XML-содержимым PCDATA. Именно это и сделано в Листинге 2. Если вы сравните эти два листинга, то обнаружите, что разметка для раздела CDATA ("<![CDATA[" в начале и "]]>" в конце) была удалена, а вместо символа "<" в разделе CDATA Листинга 1 в Листинге 2 была добавлена эквивалентная управляющая последовательность (<). Листинг 2 <?xml version="1.0"?> 15. Инструкции обработки Согласно этому требованию, необходимо нормализовать свободные места внутри инструкций обработки. Это означает, что все свободное место между объектом (target) и его данными должно быть сокращено до единственного пробела (символ #x20). В XML-файле Листинга 2 присутствует только одна инструкция обработки. Объект в этой инструкции - xml-stylesheet, за которым следует строка данных. Листинг 3 отличается от Листинга 2 только тем, что все свободное место между объектом и его данными было нормализовано. Листинг 3 <?xml version="1.0"?> 16. Ссылки на внешние сущности Вспомните соответствующий раздел первой статьи, в котором было показано, как канонизировать ссылки на разобранные внутренние сущности. Аналогичным образом ссылки на разобранные внешние сущности заменяются содержимым, на которое они ссылаются (см. Листинг 4). Листинг 4
17. Комментарии Спецификация "Канонический XML" позволяет как сохранять, так и удалять комментарии из XML-файла. Процессор канонизации XML будет получать вместе с XML-файлом, подлежащим канонизации, булевский параметр (признак), с помощью которого он сможет определить включать или не включать XML-комментарии в каноническую форму. Например, в Листинге 5 удалены комментарии, присутствующие в Листинге 4 (каноническая форма без комментариев). Теперь к Листингу 5 можно применить все тринадцать операций (описанных в первой статье). Результат этого процесса приведен в Листинге 6. Листинг 5 <?xml version="1.0"?> Листинг 6 <?xml-stylesheet href="http:/www.myFictitiosCompany.com/style-sheet.xsl" type="text/xsl" ?> 18. Подмножества документов Подмножества или фрагменты (части целых XML-файлов) XML-документов представляют очень интересный случай. Когда мы извлекаем из XML-файла некоторую его часть, мы неизбежно отделяем узел потомок (child node) от его родителя (назовем его "осиротевший" узел [orphan node]). Это отделение может привести к недопустимости контекста пространства имен потомка, если контекст пространства имен "осиротевшего" потомка был объявлен в родителе, который не был включен в подмножество документа. Спецификация "Канонический XML" предусматривает метод, позволяющий сохранить контекст пространств имен при извлечении подмножества документа. Однако, существуют такие сценарии, в которых сохранение контекста пространств имен может приводить к ряду проблем. Поэтому консорциум W3C издал отдельную рекомендацию - "Исключающая канонизация XML" (Exclusive XML Canonicalization) - которая предназначена для управления такими сценариями. Единственное различие между спецификациями "Канонический XML" и "Исключающая канонизация XML" состоит в том, что предшествующий контекст (ancestor context) либо сохраняется, либо удаляется. Сохранение предшествующего контекста Рассмотрим Листинг 7, который является сообщением SOAP. Листинг 7 <?xml version="1.0"?> Предположим, что нам необходимо канонизировать элемент 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, применив к нему последовательность из тринадцати шагов, описанных в первой статье. Однако, прежде чем сделать это, необходимо выполнить дополнительную обработку, чтобы устранить пару проблем:
Листинг 8 <bs:booking unitCharge="50" Указанные сложности свидетельствуют о том, что при извлечении фрагментов документа необходимо придерживаться некоторых правил, которые позволят сохранить контекст пространства имен и смысл атрибутов из пространства имен xml:. Согласно спецификации "Канонический XML", при канонизации подмножеств документа необходимо выполнить следующие требования (помимо всех остальных, касающихся канонизации целых XML-файлов):
Эти два положения предназначены для сохранения предшествующего контекста подмножества документа. Так, в Листинг 9 вошли четыре объявления пространств имен, выполненых в предках элемента booking в Листинге 7. Листинг 9 также содержит атрибут xml:lang. Обратите внимание, что каноническая форма подмножества документа не включает ни одного символа перевода строки (#xA), то есть весь файл - это одна строка. Листинг 9 <bs:booking xmlns:bs="http://www.FictitiousTourismInterface/BookingService" После добавления предшествующего контекста порядок объявлений пространств имен и атрибутов должен быть таким же, как при канонизации целого 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) действительно имеет место. Листинг 10 <?xml version="1.0"?> В Листинге 11 приведена каноническая форма элемента booking Листинга 10. Это та каноническая форма, которой воспользуются работники отеля для того, чтобы создать профиль сообщения. Листинг 11 <bs:booking xmlns:bs="http://www.FictitiousTourismInterface/BookingService" С другой стороны, вспомните о том, что Листинг 9 являлся канонической формой того же элемента booking, когда он был частью Листинга 7. Вот почему клиент турфирмы воспользуется Листингом 9, чтобы проверить профиль сообщения, полученный из отеля. Если вы сравните Листинги 11 и 9 , вы заметите, что они отличаются друг от друга. Причина этого различия заключается в том, что, канонизируя один и тот же элемент booking, мы сохранили предшествующий контекст из двух различных XML-документов. Поэтому клиентское приложение (клиента турфирмы) не сможет проверить подпись и профиль сообщения. Это является исчерпывающим доказательством того, что при реализации концепции канонизации в случае объединенных Web-служб необходимо исключать предшествующий контекст. Именно с этой целью и была опубликована рекомендация "Исключающая канонизация XML". Исключающая канонизация применяется только при канонизации фрагментов XML-файлов; ниже приведены ее основных отличия от рекомендации "Канонический XML":
Обратите внимание на то, что второе правило относится также и к объявлениям пустых используемых по умолчанию пространств имен (xmlns=""). Это означает, что исключающая каноническая форма элемента будет включать объявления xmlns="", если этот элемент принадлежит к пустому используемому по умолчанию пространству имен, а в объявлении используемого по умолчанию пространства имен для ближайшего предшественника в исключающей канонической форме присутствует непустое используемое по умолчанию пространство имен (xmlns="http://someURI..."). Применив эти правила к элементу Листинга 10, можно получить исключающую каноническую форму, представленную в Листинге 12. Обратите внимание на то, что исключающая каноническая форма первого элемента Листинга 7 (значение атрибута unitCharge равно 50) точно такая же, как в Листинге 12. Листинг 12 <bs:booking xmlns:bs="http://www.FictitiousTourismInterface/BookingService" currency="USD" Неразрешенные сценарии Следует заметить, что использование спецификации "Канонический XML" может привести к возникновению следующих двух проблем:
Ресурсы
|
|
|
| ||||||||||||||||
| ||||||||||||||||
| ||||||||||||||||
|