XML - budoucnost blízká či vzdálená? - Grafika.cz - vše o počítačové grafice

29. března 2000, 00.00 | Publikace nezávislé na médiu, publikování z databází, oddělování obsahu a formy publikace. To vše jsou pojmy, které slyšíme stále častěji.

Publikace nezávislé na médiu, publikování z databází, oddělování obsahu a formy publikace. To vše jsou pojmy, které slyšíme stále častěji. Spolu s nimi se o slovo hlásí i nové aplikace. Jak se změní způsoby přípravy dokumentů po příchodu avenue.quark a standardu XML?

Avenue.quark je, jak konečně i jméno napovídá, produkt z dílny firmy, která již v pre-pressu svůj nesmazatelný otisk zanechala. I když je avenue.quark svou formou "jen" plugin do QuarkXPressu (od verze 4.04), svou funkcí slibuje mnohé. Podle zatím dostupných informací se firmě Quark povede uvést vůbec první funkční (v takovém rozsahu) řešení pro práci s XML - avenue.quark se má totiž dostat na trh na jaře tohoto roku. Spolu s avenue.quark jsou, nebo v dohledné době budou, k dispozici i další produkty Quark pro databázové publikování a správu digitálních zdrojů. Kde to bude účelné, tak je zmíníme, i když hlavním námětem článku zůstává avenue.quark a XML.

Rozumíme ale pojmům z úvodu článku správně? Co to přesně znamená publikování z databází (Database driven publishing), jaké přínosy pro vydavatelskou praxi od jeho zavedení můžeme očekávat? A jaký je vůbec rozdíl mezi publikováním nezávislým na médiu (Media independence publishing) a publikováním pro více médií (Cross-media publishing)?

Abychom se při výkladu všech nových pojmů trochu přiblížili praxi, představme si fiktivní obchodní firmu střední velikosti, jež vytváří, udržuje a publikuje větší množství ceníků, katalogů a vnitrofiremních materiálů. Když říkáme publikuje, máme na mysli (mimo jiné) tištěné materiály, vystavení materiálů na firemních stránkách (případně i výrobu propagačních CD), rozesílání tiskových zpráv, rozesílání personalizovaných tiskovin.

Dosavadní praxe se vyznačuje hlavně tím, že jiné než původně zamýšlené využití již jednou zpracovaných dokumentů s sebou nese další bezprostřední finanční náklady a časové ztráty. Dokumenty jsou dnes příliš jednoúčelové, zdánlivě jednoduchý úkol publikovat třeba současně tištěné a internetové verze katalogů se může ukázat nad síly naší fiktivní společnosti. Je jasné, že potřebujeme pomoc, nové postupy a nové aplikace tam, kde ty původní nestačí.

Databázové publikování je prvním z nástrojů, které pomoc mohou nabídnout. Naše obchodní firma má informace o zboží (ceníky, kódy) uloženy v databázi. V jiné databázi mohou být uloženy informace o parametrech produktů, jejich fotografie apod. Umíme údaje z databáze cen automaticky vkládat do připraveného formuláře na Internetu? Pak jsme zvládli základ databázového publikování. Ale co když chceme z téže databáze vybrat odlišný soubor údajů, a ten vkládat kromě www i do stránek tištěných letáků spolu s údaji z databáze parametrů a vzhledu produktů?

V prvé řadě budeme potřebovat nástroj, který dokáže využít data jak pro tištěnou, tak i pro elektronickou produkci. Ani tady ještě nejde o převratnou (alespoň ve světě) změnu přístupu. Je ale nutné uvědomit si určitý rozdíl v dnes běžnějším meziplatformním publikování a publikování nezávislém na médiu. Při meziplatformním publikování obvykle již při vytváření dokumentu víme, jak bude publikován - například jako leták a na www stránkách. Úměrně tomu volíme aplikace a výsledkem většinou bývá (a to je důležité) dokument, který je ve všech médiích shodný nebo velmi podobný.

Publikování nezávislé na médiu, a o to v našem článku jde v první řadě, má sice v zásadě velmi podobný cíl, podstatně se ale liší v přístupu. Autor vytváří dokument, který je "osvobozen" od formy. Není potřeba znát design dokumentu, ani to, jakou formou bude publikován nebo dále zpracováván. Jak je to možné, proč není svázán omezeními www stránek, proč se nazjímá o způsob tisku?

Odpověď na otázky v předcházejících odstavcích nabízí standard XML a aplikace, které jej podporují, což je ovšem v pre-pressu v současné době prakticky jen avenue.quark. V druhé části článku se podíváme na princip XML daleko podrobněji, nyní jen trochu předběhneme. Soubor ve formátu XML se skládá z bloků dat (textu), uzavřených mezi značkami (značce se říká tag). Kdesi je definováno, jaké značky patří k různým druhům dat - snadno tak rozeznáme, je li uvnitř značek uzavřeno telefonní číslo nebo nadpis výroční zprávy. A víc nás vlastně nemusí zajímat - když vytváříme ceník, proč se zabývat tím, jestli budou nadpisy vytištěny tučně? O to se postarají jinde a jindy aplikace, které budou mít za úkol dát datům v XML souboru konkrétní formu - třeba právě avenue.quark.

Avenue.quark bude plnit hned dvě základní funkce. První je zřejmá, mluvíme o importu XML dat do stránek v QuarkXPressu. To je v každém případě jednodušší postup, možná trochu připomínající skládání dopisů z databázových záznamů ve vyspělém textovém editoru. Předpokládejme, že z tiskové agentury přicházejí do redakce novin pravidelné zprávy o počasí, přehledně členěné do předem známých bloků (teplota ráno, vítr ráno...) ve formátu XML. Přesně, jak bychom čekali, do stránek v QuarkXPressu zakomponujeme cosi jako záložky, které jsou na výstupu průběžně nahrazovány skutečnými daty - předpověď počasí se na stránce novin objevuje automaticky, s minimálním zásahem obsluhy.

Prakticky všichni, kdo nějakou dobu pracují s QuarkXPressem, uchovávají velké množství dat, často velmi důležitých, ve formě QuarkXPress dokumentů. Avenue.quark jim poskytuje nedocenitelnou službu v tom, že umožňuje převádět archivní quarkovské dokumenty do XML. Na praktickém příkladu snadno pochopíme, jak avenue.quark pracuje; zároveň poznáme i limity automatizovaného převodu archivních (to je důležité) dokumentů do XML. Abychom získali z avenue.quark maximum slibovaného výkonu a produktivity, je třeba, aby dokumenty měly jednotnou formu, nebo alespoň co nejvíce společných prvků. V opačném případě sice stále můžeme dokumenty do XML převádět, bude to ale zdlouhavé a obtížné.

Aby avenue.quark mohla převádět dokumenty do XML, potřebuje jednu nebo více definicí DTD (ještě o nich bude řeč). Každá definice obsahuje seznam povolených elementů. Tak například může DTD definovat elementy <nadpis> a <text>, které později nalezneme v XML souboru jako tagy. DTD má definovat i jejich vzájemnou posloupnost, třeba že nesmí následovat dva nadpisy ihned po sobě a text nesmí předcházet nadpisu. Než se avenue.quark pustí do prvního převodu, musí uživatel definovat, které styly, použité v sazbě, budou označovány jednotlivými tagy. Je obecně známo, že QuarkXPress nabízí možnost formátovat text pomocí tzv. stylů odstavců. A obsluha v tomto případě nedělá nic jiného, než že ručně definuje: styl odstavce "Hlavička" bude v XML uzavírán mezi tagy <nadpis>; následující blok textu, formátovaný stylem "Text_A" bude uzavírán mezi tagy <text>. Aplikace mimochodem umožňuje uživateli uložit XML dokument ve formě předlohy (template), která podchycuje konkrétní definici DTD a soubor přiřazených vazeb na tagy - usnandní se tak převádění více navzájem odlišných typů dokumentů. Jakmile vytvoříme vazby mezi styly v dokumentu a příslušnými tagy (nebo zvolíme příslušnou dříve připravenou předlohu), můžeme přikročit k převodům. Jednoduše otevřeme QuarkXPress dokument a spustíme převod. Avenue.quark najde všechny známé styly odstavců, vezme obsah těchto odstavců a uzavře jej mezi určené tagy. Pokud v dokumentu zbydou objekty, které nelze nikam zařadit, obsluha je může označit ručně (například nějakým univerzálním tagem). Stejně tak je možné do dokumentu před převodem přidat (a opět označit) i informace nové, které se v původním dokumentu nevyskytovaly. Tím je převod ukončen a nově vzniklý XML dokument je možné ukládat.

Velmi dobře tu vidíme, jak převod do XML funguje. Není to jako generování PDF, kdy aplikace "vstřebá" sebesložitější dokument, jeden každý zcela odlišný od předcházejícího. Převody archivního dokumentu budou jen výjimečně úplně automatické, bez zásahu obsluhy. Lze říci, že největší část práce připadne, a nejen v případě archivních dokumentů, na předběžné definice efektivních datových struktur.

Teď, když máme určitou praktickou představu, jak XML vypadá a funguje, představíme si tento standard blíže, podrobněji, a naznačíme souvislosti s technologiemi pro elektronické publikování. Vizuální i zvuková podoba XML s dalšími zkratkami XHTML a HTML nám na první pohled orientaci moc neusnandní. HTML je přece jazyk, ve kterém jsou vytvářeny stránky internetových serverů, a pokud ty něčím vynikají, typografické možnosti to zrovna nejsou. Jaká tu je souvislost? Lze v XML uchovávat reálné tiskoviny, nabídne dostatečné možnosti úpravy dokumentu?

XML je částí, podmnožinou standardu SGML (Standard Generalized Markup Languague, ISO 8879). A to už žádný nováček není, vznik SGML můžeme zaznamenat již počátkem 80. let. Po postupném vývoji se z SGML stal široký mezinárodní průmyslový standard (norma ISO následovala v roce 1986), který je využíván jako společný formát pro rozsáhlé soubory, zejména technických dokumentů. SGML je obšírná, univerzální definice, která dokáže pojmout prakticky jakýkoliv druh dokumentu, od chemických vzorců po třeba zápis šachové partie, ze kterého jsou v novinách automaticky tištěny důvěrně známé herní diagramy. Celkem logicky ale snadno odhalíme základní nevýhodu SGML - pro běžné komerční použití je to popis až příliš složitý, jeho použití je obtížné a potřebný software nákladný.

XML, SHTML i HTML mají jedno společné, všechno jsou to tzv. metajazyky. Dokument v metajazyce nelze spouštět, jeho provedením nedojde k vyvolání žádných akcí, jako u programovacích jazyků. Základním prvkem jazyka je tzv. tag, který si můžeme zjdnodušeně představit jako označení libovolného druhu dat. Tagy ohraničují blok dat, stojí na jeho začátku i na konci. Velmi stručně si to můžeme ukázat na příkladu tagu, označujícího v metajazyku hlavičku:

<header> Toto je text hlavičky </header>

Jak vidíme, tagy jsou ve skutečnosti dva, jeden otevírací a druhý zavírací; odlišují se jen přítomností lomítka. Celý vtip je v tom, že se všichni dohodnou a vědí, jak přesně bude v té které aplikaci vypadat text, uzavřený mezi dva tagy, označující hlavičku. Všechny kompatibilní aplikace poznají, že jde o text hlavičky a zobrazí jej, přitom ale toto zobrazení nemusí být vždy stejné, jak později uvidíme. To je ono oddělení formy zobrazení od obsahu, jak jsme o něm mluvili v úvodu.

Nyní již víme, že XML, podobně jako HTML, má původ v SGML. Definice XML vznikla podstatným zestručněním SGML a přizpůsobením jazyka potřebám automatizovaného elektronického i klasického publikování. Kompatibilita směrem vzhůru zůstává samozřejmě zachována, každý XML dokument vyhovuje definici SGML. A jaký je tedy vztah XML a HTML? Jde o definice konkurenční, nebo zcela nesouvisející? Ani jedno, ani druhé - XML a HTML se doplňují, a v budoucnosti se jejich provázanost zřejmě ještě prohloubí. Každý se ovšem v procesu publikace dokumentu stará o něco jiného:

• XML popisuje data, zajímá se o obsah informace, nesené dokumentem;
• HTML data zobrazuje, zajímá se o to, jak budou data vypadat;
• XML dovoluje definovat vlastní (uživatelské) tagy a nové struktury dokumentů;
• HTML je pevně předdefinováno, autor dokumentu se musí držet standardu.

Kromě uvedených zásadních odlišností se definice XML dočkala oproti HTML několika formálních změn - jen pro představu, nesmějí se vynechávat ukončovací tagy, v názvech tagů se zohledňují velká a malá písmena - to jsou ale z našeho úhlu pohledu detaily.

Jak je vidět, XML není na rozdíl od HTML určeno pouze pro elektronické publikování. Dokumenty formátované v XML mohou být publikovány, přesněji řečeno VYUŽÍVÁNY, širokým spektrem aplikací pro nejrůznější účely - HTML je jen jednou z cest, jak XML dokument zobrazit. Poznamenejme, že právě nyní vchází v platnost nová definice XHTML 1.0, což je vlastně nejnovější verze HTML 4.0, ovšem přepracovaná tak, aby vyhověla požadavkům, kladeným na XML dokumenty.

Pro větší názornost si představme, že XML dokument bude obsahovat položku telefonního čísla:

<telefon> 02 xxx xxx xx </telefon>

Telefonní číslo může být vloženo do prospektu, uvedeno na www stránce, zařazeno do interní databáze klientů, nebo třeba vytočeno - podle toho, která aplikace se (stále jednoho a téhož) dokumentu chopí.

Nedocenitelnou a zásadní výhodou XML je, že nabízí při konkrétní implementaci možnost tvorby vlastní struktury dokumentu, včetně vlastních tagů. Tak velká rozšiřitelnost je možná díky koncepci DTD (Document Type Definition). DTD jsou tím místem, kde strukturu dokumentu a jednotlivé tagy navrhujeme, stejně dobře ale můžeme využít i některé ze standardních DTD - do důsledku vzato, jako DTD může sloužit třeba právě HTML. Je přitom jasné, že aby aplikace mohly sdílet XML soubory, musí disponovat příslušnými DTD soubory - jinak budou dokumenty nesrozumitelné. Podobně jako v HTML s jeho CSS, mohou i XML dokumenty využívat společné, externě uchovávané DTD, se všemi výhodami i nevýhodami takového uspořádání (mezi nevýhody patří například možnost obtížně kontrolovatelného útoku na systém prostřednictvím záměrné modifikace externích DTD).

Možnosti formátování dokumentů a využívání v nich obsažených informací prostřednictvím DTD jsou na druhé straně prakticky nevyčerpatelné. Závisí jen na množství umu a práce, vložené do definice struktury dokumentu a na vhodném výběru aplikačního software, schopného s XML dokumenty pracovat. V nových verzích podporují (nebo budou podporovat) XML oba nejznámější internetové prohlížeče, MS Internet Explorer 5 a chystaný Netscape 5, postupně jsou uváděny i další aplikace (prohlížeč Mozilla). Řada výrobců nabízí tzv Parsery, což jsou utility, schopné XML dokumenty číst i zpracovávat (zobrazovat). Ty se pak mohou stát základem dalšího aplikačního software. Jinak ale vhodného software zatím mnoho není - jako jeden z prvních zřejmě do cíle dorazí avenue.quark.

Všechny signály od předních producentů svědčí o tom, že standard XML se v krátké době stane jedním z klíčových nástrojů. V XML mohou být uloženy prakticky veškeré firemní údaje, od ceníků zboží až po vnitřní telefonní seznam společnosti. Ze souboru si bere potřebné údaje aplikace, zveřejňující ceník na Internetu, stejně jako aplikace, která vypracuje přehled úspěšnosti jednotlivých produktů, který ve formě tabulky pošle ekonomickému řediteli a ve formě PDF jako tiskovou zprávu umístí na Internet. Avenue.quark je prvním nadějným hráčem a rozhodně ne posledním - nechme se překvapit.

Článek byl převzat z čísla 3/2000 měsíčníku Svět tisku, které vychází tento týden. Bližší informace o časopisu naleznete na www.svettisku.cz.