Канонізація XML (Частина 2), HTML, XML, DHTML, Інтернет-технології, статті

Білал Сіддікуі

У попередній статті, присвяченій Рекомендації W3C “Канонічний XML” (Canonical XML), розповідалося, чому і коли необхідно канонізувати XML-файли. Крім того, в ній послідовно – крок за кроком – Був показаний процес отримання канонічної форми XML-документа.

У другій і завершальній статті даного циклу ми продовжимо вивчення цієї концепції і розглянемо вимоги, що пред’являються до розділів CDATA, інструкції обробки (processing instruction), коментарів, посиланнях на зовнішні сутності (external entity) і підмножини XML-документів.

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

Лістинг 1

<?xml version="1.0"?>
<?xml-stylesheet target=_blank href="http:/www.myFictitiosCompany.com/style-sheet.xsl" type="text/xsl" ?>
<!DOCTYPE product [
<!ATTLIST part approved CDATA "yes">
<!ENTITY testhistory SYSTEM "http:/www.myFictitiosCompany.com/testhistory.txt">
]>
<!-- We assume that the file referenced by the "testhistory" external entity contains the following string:

Part has been tested according to the specified standards.

-->
<product xmlns="http://www.myFictitiousCompany.com/product"
            xmlns:sup="http://www.myFictitiousCompany.com/supplier"
            name='rotating disc "Energymeter"'
            id="P184.435"
            classification = "MeasuringInstruments/Electrical/Energy/">
    <parts>
        <part id="P184.675"
              name="bearing">
            <sup:supplier id="S1753"/>
            <sup:supplier id="S2341"/>
            <sup:supplier id="S3276"/>
            <comments>&testhistory;</comments>
        </part>
        <part id="P184.871"
              name="magnet"
              xmlns="http://www.myFictitiousCompany.com/product">
            <sup:supplier id="S3908"/>
            <sup:supplier id="S4589"/>
            <sup:supplier id="S1098"/>
            <comments>&testhistory;</comments>
        </part>
<![CDATA[Price of part P184.675 < price of part P184.871]]>
    </parts>
</product>

14. Розділи CDATA

Канонічна форма вимагає, щоб всі розділи CDATA були замінені своїм еквівалентним XML-вмістом PCDATA. Саме це і зроблено в Лістингу 2. Якщо ви порівняєте ці дві лістингу, то виявите, що розмітка для розділу CDATA (“

Лістинг 2

<?xml version="1.0"?>
<?xml-stylesheet target=_blank href="http:/www.myFictitiosCompany.com/style-sheet.xsl" type="text/xsl" ?>
<!DOCTYPE product [
<!ATTLIST part approved CDATA "yes">
<!ENTITY testhistory SYSTEM "http:/www.myFictitiosCompany.com/testhistory.txt">
]>
<!-- We assume that the file referenced by the "testhistory" external entity contains the following string:

Part has been tested according to the specified standards.

-->
<product xmlns="http://www.myFictitiousCompany.com/product"
              xmlns:sup="http://www.myFictitiousCompany.com/supplier"
              name='rotating disc "Energymeter"'
              id="P 184.435"
              classification = "MeasuringInstruments/Electrical/Energy/">
    <parts>
        <part id="P 184.675"
              name="bearing">
            <sup:supplier id="S 1753"/>
            <sup:supplier id="S 2341"/>
            <sup:supplier id="S 3276"/>
            <comments>&testhistory;</comments>
        </part>
        <part id="P 184.871"
              name="magnet"
              xmlns="http://www.myFictitiousCompany.com/product">
            <sup:supplier id="S 3908"/>
            <sup:supplier id="S 4589"/>
            <sup:supplier id="S 1098"/>
            <comments>&testhistory;</comments>
        </part>
Price of part P184.675 < price of part P184.871
    </parts>
</product>

15. Інструкції обробки

Згідно цій вимозі, необхідно нормалізувати вільні місця всередині інструкцій обробки. Це означає, що все вільне місце між об’єктом (target) і його даними повинно бути скорочено до єдиного пропусків (символ # x20).

В XML-файлі лістингу 2 присутня тільки одна інструкція обробки. Об’єкт в цій інструкції – xml-stylesheet, За яким слід рядок даних. Лістинг 3 відрізняється від лістингу 2 тільки тим, що все вільне місце між об’єктом і його даними було нормалізовано.

Лістинг 3

<?xml version="1.0"?>
<?xml-stylesheet href="http:/www.myFictitiosCompany.com/style-sheet.xsl" type="text/xsl" ?>
<!DOCTYPE product [
<!ATTLIST part approved CDATA "yes">
<!ENTITY testhistory SYSTEM "http:/www.myFictitiosCompany.com/testhistory.txt">
]>
<!-- We assume that the file referenced by the "testhistory" external entity contains the following string:

Part has been tested according to the specified standards.

-->
<product xmlns="http://www.myFictitiousCompany.com/product"
            xmlns:sup="http://www.myFictitiousCompany.com/supplier"
            name='rotating disc "Energymeter"'
            id="P 184.435"
            classification = "MeasuringInstruments/Electrical/Energy/">
    <parts>
        <part id="P 184.675"
              name="bearing">
            <sup:supplier id="S 1753"/>
            <sup:supplier id="S 2341"/>
            <sup:supplier id="S 3276"/>
            <comments>&testhistory;>/comments>
        </part>
        <part id="P 184.871"
              name="magnet"
              xmlns="http://www.myFictitiousCompany.com/product">
            <sup:supplier id="S 3908"/>
            <sup:supplier id="S 4589"/>
            <sup:supplier id="S 1098"/>
            <comments>&testhistory;
        </part>
Price of part P184.675 < price of part P184.871
    </parts>
</product>

16. Посилання на зовнішні сутності

Згадайте відповідний розділ першої статті, в якому було показано, як канонізувати посилання на розібрані внутрішні сутності. Аналогічним чином посилання на розібрані зовнішні сутності замінюються вмістом, на яке вони посилаються (див. Лістинг 4).

Лістинг 4


<?xml version="1.0"?>
<?xml-stylesheet href="http:/www.myFictitiosCompany.com/style-sheet.xsl" type="text/xsl" ?>
<!DOCTYPE product [
<!ATTLIST part approved CDATA "yes">
<!ENTITY testhistory SYSTEM "http:/www.myFictitiosCompany.com/testhistory.txt">
]>
<!-- We assume that the file referenced by the "testhistory" external entity contains the following string:

Part has been tested according to the specified standards.

-->
<product xmlns="http://www.myFictitiousCompany.com/product"
            xmlns:sup="http://www.myFictitiousCompany.com/supplier"
            name='rotating disc "Energymeter"'
            id="P 184.435"
            classification = "MeasuringInstruments/Electrical/Energy/">
    <parts>
        <part id="P 184.675"
              name="bearing">
            <sup:supplier id="S 1753"/>
            <sup:supplier id="S 2341"/>
            <sup:supplier id="S 3276"/>
            <comments>Part has been tested according to the specified standards.</comments>
        </part>
        <part id="P 184.871"
              name="magnet"
              xmlns="http://www.myFictitiousCompany.com/product">
            <sup:supplier id="S 3908"/>
            <sup:supplier id="S 4589"/>
            <sup:supplier id="S 1098"/>
            <comments>Part has been tested according to the specified standards.</comments>
        </part>
Price of part P184.675 < price of part P184.871
    </parts>
</product>

17. Коментарі

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

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

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

Лістинг 5

<?xml version="1.0"?>
<?xml-stylesheet href="http:/www.myFictitiosCompany.com/style-sheet.xsl" type="text/xsl" ?>
<!DOCTYPE product [
<!ATTLIST part approved CDATA "yes">
<!ENTITY testhistory SYSTEM "http:/www.myFictitiosCompany.com/testhistory.txt">
]>
<product xmlns="http://www.myFictitiousCompany.com/product"
            xmlns:sup="http://www.myFictitiousCompany.com/supplier"
            name='rotating disc "Energymeter"'
            id="P 184.435"
            classification = "MeasuringInstruments/Electrical/Energy/">
    <parts>
        <part id="P 184.675"
              name="bearing">
            <sup:supplier id="S 1753"/>
            <sup:supplier id="S 2341"/>
            <sup:supplier id="S 3276"/>
            <comments>Part has been tested according to the specified standards.</comments>
        </part>
        <part id="P 184.871"
              name="magnet"
              xmlns="http://www.myFictitiousCompany.com/product">
            <sup:supplier id="S 3908"/>
            <sup:supplier id="S 4589"/>
            <sup:supplier id="S 1098"/>
            <comments>Part has been tested according to the specified standards.</comments>
        </part>
Price of part P184.675 < price of part P184.871
    </parts>
</product>

Лістинг 6

<?xml-stylesheet href="http:/www.myFictitiosCompany.com/style-sheet.xsl"   type="text/xsl"   ?>
<product xmlns="http://www.myFictitiousCompany.com/product" xmlns:sup="http://www.myFictitiousCompany.com/supplier"
classification="MeasuringInstruments/Electrical/Energy/" id="P 184.435" name="rotating disc "Energymeter"">
    <parts>
        <part approved="yes" id="P 184.675" name="bearing">
            <sup:supplier id="S 1753"></sup:supplier>
            <sup:supplier id="S 2341"></sup:supplier>
            <sup:supplier id="S 3276"></sup:supplier>
            <comments>Part has been tested according to the specified standards.</comments>
        </part>
        <part approved="yes" id="P 184.871" name="magnet">
            <sup:supplier id="S 3908"></sup:supplier>
            <sup:supplier id="S 4589"></sup:supplier>
            <sup:supplier id="S 1098"></sup:supplier>
            <comments>Part has been tested according to the specified standards.</comments>
        </part>
Price of part P184.675 < price of part P184.871
    </parts>
</product>

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"?>
<SOAP:Envelope xmlns:SOAP="http://www.w3.org/2001/12/soap-envelope">
    <SOAP:Header>

<!--Protocol specific information, such as signature etc.-->

    </SOAP:Header>
    <SOAP:Body >
        <bs:PackageBooking
            
xmlns:bs="http://www.FictitiousTourismInterface/BookingService"
            
xmlns:hs="http://www.FictitiousTourismInterface/HotelService"
            
xmlns:cs="http://www.FictitiousTourismInterface/CarRentalService"
            
xml:lang="en" Id='VacationTours/Packages[@id=435]/booking[(@date="2002-09-23T09:06:00Z")and(@number="786")]'
            issueDate="2002-09-23T09:06:00Z">

              <bs:booking unitCharge="50"
                      unitDescription="per night"
                      units="2"
                      currency="USD"
                      status="confirmed" >
                <item>
                  <hs:room hotelName="White Palace"
                          type="suite"
                          bookedFrom="2002-10-12T12:00:00Z"
                          bookedTo="2002-10-14T12:00:00Z" />
              </item>             </bs:booking>

              <bs:booking unitCharge="60"
                      unitDescription="per night"
                      units="1"
                      currency="USD"
                      status="confirmed">
                <item>
                  <hs:room hotelName="Lake View"
                          type="suite"
                          bookedFrom="2002-10-14T12:00:00Z"
                          bookedTo="2002-10-15T12:00:00Z" />
              </item>
            </bs:booking>

            <bs:booking unitCharge="200"
                      unitDescription="per day"
                      units="3"
                      currency="USD"
                      status="confirmed">
                <item>
                  <cs:car make="Toyota"
type="Hiace"
bookedFrom="2002-10-12T12:00:00Z"
bookedTo="2002-10-15T12:00:00Z"/>
                </item>
            </bs:booking>

        </bs:PackageBooking>
    </SOAP:Body>
</SOAP:Envelope>

Припустимо, що нам необхідно канонізувати елемент 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. Лістинг 8

    <bs:booking unitCharge="50" 
        unitDescription="per night"
        units="2"
        currency="USD"
        status="confirmed" >
        <item>
            <hs:room hotelName="White Palace"
                type="suite"
                bookedFrom="2002-10-12T12:00:00Z"
                bookedTo="2002-10-14T12:00:00Z" />
        </item>
    </bs:booking>
  3. В Лістингу 7 атрибут xml:lang елемента bookingPackage застосуємо для всіх своїх нащадків. Цей атрибут також відсутній в підмножині документа лістингу 8.

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

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

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

Лістинг 9

<bs:booking xmlns:bs="http://www.FictitiousTourismInterface/BookingService"
xmlns:cs="http://www.FictitiousTourismInterface/CarRentalService"
xmlns:hs="http://www.FictitiousTourismInterface/HotelService"
xmlns:SOAP="http://www.w3.org/2001/12/soap-envelope" currency="USD" status="confirmed"
unitCharge="50" unitDescription="per night" units="2" xml:lang="en"><item><hs:room
bookedFrom="2002-10-12T12:00:00Z" bookedTo="2002-10-14T12:00:00Z" hotelName="White Palace"
type="suite"></hs:room></item></bs:booking>

Після додавання попереднього контексту порядок оголошень просторів імен та атрибутів повинен бути таким же, як при канонізації цілого 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"?>
<SOAP:Envelope xmlns:SOAP="http://www.w3.org/2001/12/soap-envelope">
    <SOAP:Header>

<!--Protocol specific information, such as signature etc.-->

    </SOAP:Header>
    <SOAP:Body
        xmlns:bs="http://www.FictitiousTourismInterface/BookingService"
        xmlns:hs="http://www.FictitiousTourismInterface/HotelService">
        <bs:booking unitCharge="50"
                unitDescription="per night"
                units="2"
                currency="USD"
                status="confirmed" >
        <item>
            <hs:room hotelName="White Palace"
                    type="suite"
                    bookedFrom="2002-10-12T12:00:00Z"
                    bookedTo="2002-10-14T12:00:00Z" />
        </item>
        </bs:booking>

    </SOAP:Body>
</SOAP:Envelope>

В Лістингу 11 приведена канонічна форма елемента booking Лістингу 10. Це та канонічна форма, якої скористаються працівники готелю для того, щоб створити профіль повідомлення.

Лістинг 11

<bs:booking xmlns:bs="http://www.FictitiousTourismInterface/BookingService" 
xmlns:hs="http://www.FictitiousTourismInterface/HotelService"
xmlns:SOAP="http://www.w3.org/2001/12/soap-envelope" currency="USD" status="confirmed"
unitCharge="50" unitDescription="per night" units="2"><item><hs:room
bookedFrom="2002-10-12T12:00:00Z" bookedTo="2002-10-14T12:00:00Z" hotelName="White Palace"
type="suite"></hs:room></item></bs:booking>

З іншого боку, згадайте про те, що Лістинг 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.

Лістинг 12

<bs:booking xmlns:bs="http://www.FictitiousTourismInterface/BookingService" currency="USD"
status="confirmed" unitCharge="50" unitDescription="per night" units="2"><item><hs:room
xmlns:hs="http://www.FictitiousTourismInterface/HotelService" bookedFrom="2002-10-12T12:00:00Z"
bookedTo="2002-10-14T12:00:00Z" hotelName="White Palace"
type="suite"></hs:room></item></bs:booking>

Недозволені сценарії

Слід зауважити, що використання специфікації "Канонічний 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 і про те, як його можна використовувати цю мову.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*