Hlavní navigace

Akta X 0601

6. 2. 2006
Doba čtení: 4 minuty

Sdílet

Navrhnout aplikaci XML není tak snadné, jak by se mohlo na první pohled zdát. Pokud o tom uvažujete, třeba vás tento článek odradí, nebo vám naopak pomůže lépe uspět.

Návrh jazyků XML

O tom, zda vymýšlet či nevymýšlet nové jazyky XML, a pokud ano, jak při tom postupovat, pojednává dvojice článků od Tima Braye. Bray je v tomto ohledu dozajista povolán rozdávat moudra; je podepsán pod specifikacemi XML 1.0 a 1.1, nebo třeba Atom 1.0. Pokud máte občas co do činění s návrhem aplikací XML, určitě stojí za to přečíst si oba původní, nepříliš dlouhé články ([1], [2]).

Jak napovídá název prvního článku, Don't Invent XML Languages, Bray píše o tom, že není třeba vynalézat pro každou příležitost nový jazyk. Přestože možnost vytváření nových jazyků je od začátku považována za jednu z hlavních výhod XML, v praxi nemusí být použití vlastní aplikace XML tím nejlepším řešením. Práce na návrhu jazyka je vždy složitější a časově náročnější, než se na začátku zdá. Krom toho, aby nový jazyk mohl něčemu sloužit, bude nutné napsat spoustu softwaru. Existující obecné nástroje pro práci s XML pomohou jen do určité míry. Kdo se rozhodne pro vytvoření své vlastní aplikace XML se vším, co k tomu patří, měl by být připraven na mnoho měsíců až několik roků práce a s tím spojené nemalé náklady.

Alternativou k vynalézání vlastního jazyka je použití jednoho z těch už vynalezených. Robin Cover na svých Cover Pages uvádí seznam skoro 600 veřejně známých a dokumentovaných aplikací XML (vzpomněl bych si ještě na pár dalších). Je velmi pravděpodobné, že mezi stovkami existujících jazyků by se našel takový, který vyhoví vašim potřebám. Tim Bray jde dál a neváhá vyslovit daleko radikálnější názor. Ze stovek stávajících jazyků XML jich drtivá většina nemá reálný význam a nikdy nesplnila očekávání, která do nich jejich tvůrci vkládali. Podle něj je velmi pravděpodobné, že pro vaše účely dobře poslouží jeden z pěti významných jazyků, takzvaná „velká pětka“.

Velkou pětku představuje těchto pět aplikací XML: XHTML, DocBook, ODF, UBL a Atom. Společným jmenovatelem těchto jazyků má být jejich všeobecná znalost a používání, a z toho plynoucí výborná softwarová podpora. S tímto konkrétním seznamem pěti nejdůležitějších aplikací XML nemusí každý souhlasit. Atom se do elitní společnosti dostal na divokou kartu budoucích očekávání, někomu může chybět ten či onen významný jazyk. Základní myšlenka ale platí. Vybírat ze stovek aplikací XML a u každé ještě posuzovat, zda je kvalitně navržena a dostatečně podporována, by mohlo být ještě obtížnější než přijít s vlastním jazykem. To je nakonec asi důvod, proč mnoho z těchto jazyků vzniklo. Naproti tomu ověřit, nehodí-li se pro mé potřeby jeden z nejpoužívanějších jazyků, je rychlé a v případě kladného výsledku také velmi výhodné.

Brayova poučka pro projektové manažery tedy zní: Až za vámi přijdou vývojáři s tím, že v rámci projektu potřebují navrhnout novou aplikaci XML, vyžádejte si zdůvodnění, proč nelze použít žádný z jazyků velké pětky. Pokud se necháte přesvědčit, začněte pracovat na posunutí termínu a navýšení rozpočtu.

Neméně zajímavý je i druhý článek,On XML Language Design, pojednávajícící o tom, s čím počítat, pokud se do návrhu nového jazyka XML přece jen pustíte. První důležité rozhodnutí se týká toho, jak má být jazyk rozsáhlý. Jinými slovy, co všechno s ním budete chtít řešit. Vytvořit úzce zaměřenou minimalistickou aplikaci je rychlejší a snažší, ale pokušení přidat ještě tu nebo onu užitečnou funkci je veliké. Obzvlášť pokud na návrhu aplikace pracuje více lidí a každý má trochu jiný úhel pohledu. Praxe ukázala, že šance vymyslet napoprvé správně velmi komplexní jazyk XML je skoro nulová, a to i pro organizace typu W3C, které na to mají dostatek času a prostředků.

Je dobré nezapomínat, že vymýšlení aplikace XML je projekt jako každý jiný. Ten, kdo ho vede, by měl na začátku stanovit požadavky a cíle a snažit se o dodržení původního záměru i časového rozvrhu. Návrh jazyka typicky nebývá hlavní nebo jedinou pracovní náplní zainteresovaných. Pokud není nikdo, kdo by projekt aktivně posouval dopředu, potenciál k zacyklení diskuzí a neustálému posouvání termínů je enormní.

Autor aplikace XML by měl být smířen s tím, že se mu nepodaří vymyslet dokonalá jména pro všechny elementy a atributy. Správné pojmenování není samo o sobě nijak jednoduché, navíc v průběhu projektu dochází k významovým posunům a není možné vše stále dokola přejmenovávat.

K tvorbě jazyka lze přistoupit dvěma velmi různými způsoby. První přístup pracuje primárně s formálním objektovým modelem jazyka. Syntaxe vyplyne z modelu a vlastně na ní až tak moc nezáleží. Druhý přístup se od začátku zabývá syntaxí a jediným modelem jazyka je v tomto pojetí schéma XML. Nedá se říct, že by jeden z těchto přístupů byl správný a druhý špatný. Záleží na znalostech a zkušenostech každého konkrétního člověka. Řekl bych, že syntaxe je spíše blízká lidem, kteří v XML vidí textové dokumenty, zatímco k modelování mají sklony ti, kdo XML chápou jako formát pro serializaci dat.

root_podpora

Starostí se nezbavíte ani poté, až bude aplikace XML úspěšně vytvořena. Předpokládejme, že máte úspěch; vývojáři pro aplikaci vyvíjejí a uživatelé si ji užívají. Co s takovou aplikací dál? Zakonzervovat a neměnit, aby programátoři měli stabilní specifikaci? Nebo shromažďovat reakce uživatelů a pracovat na nové, ještě lepší verzi jazyka? Univerzální správná odpověď ani tentokrát neexistuje, historicky se ale přece jen více osvědčuje mírně konzervativní přístup. Pro příklady druhých verzí úspěšných jazyků, které jsou zatím přijímány rozpačitě, není třeba chodit daleko (XML 1.1, XPath/XSLT 2.0).

Stručné shrnutí doporučených postupů pro architekty jazyků XML by mohlo znít třeba takto: Snažte se udržet jazyk malý a zaměřený na jednu věc, nepodceňujte řízení projektu a nečekejte, že výsledek bude dokonalý.

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