Hlavní navigace

Úskalí XML (4)

31. 1. 2003
Doba čtení: 4 minuty

Sdílet

W3C XML Schema 1.0 je zatím nejobsáhlejší specifikací z oblasti XML. Autoři se pravděpodobně snažili vtěsnat do WXS veškeré funkce, které pokládali za užitečné. Výsledkem je málo srozumitelný standard, jehož všechny aspekty ovládá a v praxi využije málokdo. Přesto se WXS krok za krokem prosazuje.

W3C XML Schema

Přes rozpačité přijetí si WXS pomalu získává pozici důležitého standardu mezi jazyky pro popis schémat dokumentů XML a stále více uživatelů si s ním musí poradit. Velká část z nich volí praktický přístup. Namísto teoretického studia všech jemných detailů se omezují na ovládnutí a používání základních funkcí vhodných pro jejich účely. Všem, kdo mají s WXS co do činění, se může hodit upozornění na některá úskalí, na něž mohou při práci s WXS narazit.

Každé schéma může obsahovat lokální a globální deklarace elementů. Zatímco globální elementy patří do cílového jmenného prostoru schématu, lokální nemají standardně žádný jmenný prostor.

<xs:schema xmlns:xs="http://www.w3c.org/2001/XMLSchema"
  targetNamespace="http://gingerall.org/ns">

  <!-- globální deklarace elementu-->
  <xs:element name="root">
    <xs:complexType>

      <xs:sequence>
        <!-- lokální deklarace elementu-->
        <xs:element name="node" type="xs:string"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element name="root">

</xs:schema>

Elementy node z tohoto příkladu nepatří do cílového jmenného prostoru. Stejný přístup, jaký u atributů příhodně rozlišuje příslušnost k oddílům v rámci jmenného prostoru, u elementů působí problematicky. Chceme-li, aby i lokální elementy spadaly do cílového jmenného prostoru, je třeba si to explicitně vynutit pomocí atributu elementFormDefault. Pokud nemáte vážný důvod postupovat jinak, měl by být tento atribut vždy nastaven na hodnotu „qualified“.

<xs:schema xmlns:xs="http://www.w3c.org/2001/XMLSchema"
  targetNamespace="http://gingerall.org/ns"
  elementFormDefault="qualified">

Některé podmínky (např. xs:key, xs:keyref nebo xs:unique) lze ve schématech WXS vyjádřit pomocí selektorů XPath. Při jejich psaní by měly být správně použity prefixy a jmenné prostory. Autor schématu se musí orientovat v tom, které deklarované elementy patří do cílového jmenného prostoru a které nikoliv, a nesmí zapomenout, že defaultní jmenný prostor se ve výrazech XPath neuplatňuje.

Schéma se může obejít i bez cílového jmenného prostoru. Pokud takové schéma zahrneme do jiného schématu s cílovým jmenným prostotem, platí tento jmenný prostor i pro elementy a atributy zahrnutého schématu. Obsahuje-li však původní schéma selektory XPath, nový cílový jmenný prostor se na ně nemusí uplatnit a podmínky mohou ztratit svůj smysl. Používat selektory XPath v dílčích schématech určených k zahrnutí do cílového jmenného prostoru je tudíž krajně neprozíravé.

WXS dovoluje specifikovat předvolené hodnoty elementů a atributů. Je na uvážení každého autora schématu, zda opravdu chce, aby jeho dokumenty byly bez schématu neúplné a po validaci obsahovaly jiné informace než před validací. Pokud už implicitní hodnoty použijete, neměla by jimi být kvalifikovaná jména. Nikde totiž není přesně specifikováno, co se má stát, pokud je pro URI jmenného prostoru kvalifikovaného jména ve validovaném dokumentu deklarován jiný prefix než ve schématu, případně není deklarován žádný.

<!-- schéma -->
<xs:schema xmlns:xs="http://www.w3c.org/2001/XMLSchema"
  xmlns:p1="http://foo"
  targetNamespace="http://gingerall.org/ns">

  <xs:element name="node" type="xs:QName" default="p1:value"/>

  [...]

</xs:schema>

<!-- dokument -->
<root xmlns:p2="http://foo">
  <node/>
</root>

Má být dokument po validaci doplněn na <node>p1:valu­e</node>nebo <node>p2:valu­e</node>? Jediná správná a logická odpověď neexistuje. Implementace WXS se budou s velkou pravděpodobností v řešení těchto nepřehledných situací rozcházet. Implicitním hodnotám v podobě kvalifikovaného jména je rozhodně lepší se vyhnout.

CS24_early

Další často zmiňovanou slabinou WXS je restrikce složených typů. Restrikce umožňuje odvodit ze základního typu nový typ, jehož rozsah možných hodnot je podmnožinou rozsahu základního typu. Komplexní typy se deklarují výčtem; restrikce komplexního typu pak obsahuje výčet omezení oproti původnímu typu. Při každé změně definice základního typu je proto nutné zkontrolovat a případně upravit všechny restrikce tohoto typu. Tento princip neškáluje. Údržba rozsáhlých schémat s dlouhými řetězci typů odvozených restrikcí se může snadno stát noční můrou. Krom toho jsou restrikce samy o sobě poměrně složité a je velmi pravděpodobné, že někde uděláme chybu, případně že náš procesor WXS obsahuje v této oblasti chybu. Kdo může, udělá lépe, když restrikce ve svém schématu vynechá.

Podobně je jistější obejít se i bez ostatních pokročilých funkcí WXS, jako jsou například abstraktní typy nebo redefinice typů. Stručný průvodce obezřetného uživatele jazyka WXS by mohl vypadat třeba takto: Vytvářejte přehledná schémata omezená na základní funkce (lokální a globální elementy a atributy, jednoduché typy, anonymní a pojmenované komplexní typy). Udržujte schémata co nejlépe čitelná lidským okem. Ověřujte validaci proti schématu s více procesory WXS. Nepovažujte WXS za jediný validační jazyk; možná se pro vaše účely lépe hodí jiný, např. RelaxNG nebo Schematron.

Byl pro vás článek přínosný?