Dotaz: Jak strukturovat xml - multijazykové dokumenty

[Lukáš]

Dobrý den všem,

pracuju na návrhu datového modelu pro multijazyčný dokument a nevím, co je výhodnější, zda uvnitř elementu definovat další subelementy pro každý podporovaný jazyk nebo zda to ošetřit atributy. V podstatě tedy řeším, zda je leší varaianta A nebo B níže:

A:

<element>
<cs>Cesky text</cs>
<en>Anglicky text</en>
<fr>Francouzsky text</fr>
</element>

nebo

B:

<element lang="cs">Cesky text</element>
<element lang="en">Anglicky text</element>
<element lang="fr">Francouzsky text</element>

Odpovědi

[JS]

V XML se nevyznam (vubec), ale prijde mi smysluplnejsi to druhe. V prvnim pripade bude patrne potreba zabudovat mnozinu jazyku do schematu, v druhem pripade nikoli. Ta druha situace mi prijde v praxi flexibilnejsi.

[Kit]

Oba přístupy jsou ve své podstatě rovnocenné. Puristé budou možná dávat přednost způsobu A, ale praktičtější asi bude B.

[Josef Kufner]

Já bych raději použil JSON a variantu A. Pro XML se ale hodí více B, neboť definovat element pro každý jazyk je ošklivé. Asi bych ale použil variantu C (pokud bych opravdu musel použít XML):

<element>
  <value lang="cz">Český text.</value>
  <value lang="en">English text.</value>
  <value lang="fr">Texte français.</value>
</element>

[Jirka W.]

Případně variantu D:

<element id="text1">Defaultní text, pokud není v dospozici překlad</element>

a překlady bych měl v externím xliff souboru (o xliff víc napoví google). U většího projektu by tak mohly překlady dělat pomocí profesionálních nástrojů (třeba Qt Linguist nebo komerční produkty).

Pokud bych použil variantu B nebo C, tak bych místo lang použil standardní xml:lang.

[Josef Kufner]

Přijde na to, zda se jedná o kus programu nebo kus uživatelských dat. V případě programu se externí soubor a překládací nástroj hodí. V případě dat je lepší si nekomplikovat život a uložit to na jednu hromadu.

[xkucf03]

Přiznám se, že někdy váhám, jestli ty elementy ještě takhle obalovat (varianta C) nebo ne. Nějaké argumenty pro a proti?

(samozřejmě jsou případy, kdy je to jasné, např. ten obalující element se tam může vyskytovat víckrát a má nějaké ID nebo jiné vlastnosti/atributy – pak je jasné, že ty elementy s hodnotou takto seskupíme/obalíme a společné atributy uvedeme jen jednou v tom obalu, než abychom je duplikovali ke každé hodnotě)

[Josef Kufner]

Záleží na tom, zda je jazyk vlastností elementu (samostatná instance pro každý jazyk), nebo je přeložený text alternativní hodnotou vlastnosti elementu (jedna instance pro všechny jazyky).

[xkucf03]

Příklad 1:

<program>
	<název jazyk="cs">Textový editor</název>
	<název jazyk="en">Text editor</název>
	<ikona>/usr/share/…/editor.png</ikona>
	<cesta>/usr/bin/…</cesta>
	…
</program>

Příklad 2:

<program>
	<název>
		<hodnota jazyk="cs">Textový editor</hodnota>
		<hodnota jazyk="en">Text editor</hodnota>
	</název>
	<ikona>/usr/share/…/editor.png</ikona>
	<cesta>/usr/bin/…</cesta>
	…
</program>

Jazyk je vlastností elementu název (je tam víc instancí názvu – pro každý jazyk jedna) a zároveň přeložený text je alternativní hodnotou vlastnosti název elementu program (jedna instance pro všechny jazyky).

[Josef Kufner]

Hehe, přesně tohle mne napadlo, když jsem ten předchozí příspěvek psal, ale byl jsem líný to vytvořit.

No, asi jsem měl místo slova "element" použít "entita". V XML dává větší smysl první varianta, ale v programu z toho nakonec stejnak bude muset vzniknout to druhé. Tohle je jeden z důvodů, proč nemám rád XML a mám rád JSON.

[xkucf03]

XML je v tomhle právě lepší – můžeš v něm mít i vícenásobné atributy (jako třeba v LDAPu). Jak si to přemapuješ do objektového modelu je už na tobě – tam z toho nakonec asi nějaký ten seznam/sadu uděláš, ale taky to nemusíš na objekty mapovat vůbec – může se to mapovat na relační databázi nebo to jít do tisku nebo třeba volat nějaký kód na základě SAX událostí. Mapování XML na objekty je fajn, šetří to spoustu práce, ale ne vždy je nutné nebo žádoucí.

[Josef Kufner]

S tímhle mám právě zkušenost značně negativní. XML je tak výřečné, že jakákoliv práce s ním je příliš náročná. Vem si, že XML dokument má nějakých 12 typů uzlů, struktura může být docela šílená, a přitom neumí základní datové typy (např. int nebo bool), takže je potřeba je nějak emulovat (např. trojstavový bool (true/false/nedefinováno) je lahůdka).

Oproti tomu takový JSON má tři typy uzlů (object, array a value). A data tvoří jednoduchý a snadno zpracovatelný strom, který je navíc 1:1 vyjádřitelný základními strukturami v dynamicky typovaných jazycích. Kdysi jsem byl smutný z toho, že v něm nejsou ani komentáře. Ale co ho intenzivněji používám, jsem za to rád, neboť i taková drobnost by značně komplikovala zpracování.

[xkucf03]

xs:integer, xs:boolean a mnoho dalších včetně podtypů (např. text o určité délce, rozsahu nebo vyhovující regulárnímu výrazu). Trojstavový boolean uděláš jako nepovinný atribut nebo element typu xs:boolean.

[Josef Kufner]

To opravdu ke každému kusu XML vyrábíš i schema a ke všemu, co dostaneš ho máš?

[xkucf03]

Pokud to XML má sloužit ke komunikaci¹ s někým dalším, tak ano, schéma² by tam vždy mělo být. Stejně musíš někde zdokumentovat, jak se ty elementy a atributy jmenují, jaká je kardinalita, jaké hodnoty se do nich mají zapisovat… Tak proč to neudělat rovnou ve strojově čitelné podobě?

Jak to děláš u JSONu, když si chceš dohodnout nějaký formát pro výměnu dat?

_{[1] nebo třeba konfigurák nějakého programu
[2] pokud je někomu zatěžko psát XSD, tak může napsat třeba Relax NG v kompaktní syntaxi, to počítám taky jako schéma}

[Josef Kufner]

Stejně

Ale nepotřebuju to k tomu, abych rozeznal true od "true", takže mám lepší šanci správně interpretovat data bez schema.

Co jsem tím však chtěl říct je, že převod z XML do interní reprezentace v programu je zbytečně komplikovaný, protože XML je příliš mocné. Tím přidělává práci a zesložiťuje programy, tedy minimálně jejich načítací a ukládací části (nemyslím jen XML parser, ale i to, co interpretuje samotná data).

[xkucf03]

Stejně

Vím, že to existuje, ale ještě jsem to nikoho neviděl používat v praxi. Zato XSD a Relax NG schémata potkávám běžně. (a ne, nemělo by to být selektivní slepotou, protože JSON API vídám – bohužel – celkem často)

Ale nepotřebuju to k tomu, abych rozeznal true od "true", takže mám lepší šanci správně interpretovat data bez schema.

Když jen tak nakoukneš na nějakou ukázku dat, abys měl hrubou představu, tak je to celkem jedno – stejně u toho musíš přemýšlet a vycházet ze svých zkušeností – když např. někde čteš <price/> tak tě napadne, že to uvnitř asi bude cena, jestli to chápeš jako "490" nebo 490 je v tuhle chvíli jedno.

Když ten formát chceš seriózně používat a vytvářet v něm i vlastní data nebo spolehlivě pracovat s cizími daty, tak stejně potřebuješ kompletní a závaznou dokumentaci k dané verzi formátu. A tam se dozvíš i o atributech a elementech, které v těch ukázkových datech nebyly, zjistíš z toho kardinalitu („aha, tohle tam může být víckrát“) nebo význam hodnot – např. že u některých se nepoužívá znaménko mínus a píší se tam jen nezáporná čísla, protože ten zápor je implicitní (např. uvnitř <sleva/>) nebo jak se zapisují procenta (může to být 0-1 s desetinnými místy ale taky 0-100). JSON rozlišuje jen tři primitivní datové typy (string, number, boolean), neříkám, že je to úplně na nic, ale je to takové polovičaté – jen zlomek informací, které k práci s nějakým formátem nebo API potřebuješ. Přijde mi lepší mít ten základní formát/syntaxi jednodušší, tohle tam neřešit (čísla a booleany zapisovat do stejných uvozovek jako texty) a pak mít komplexní typový systém ve schématu.

Tím přidělává práci a zesložiťuje programy, tedy minimálně jejich načítací a ukládací části (nemyslím jen XML parser…

Parsery jsou stejně už napsané a taková zátěž to taky není. Ale kde je potřeba maximální efektivita, tam je stejně blbost používat textový formát a bude to binární.

…ale i to, co interpretuje samotná data).

XInclude a entity ti předžvýká parser. A ty už si pak odchytíš jen to, co tě zajímá – určité elementy, atributy a text.

Nebo použiješ mapování mezi XML a objekty – to už je pro tebe jen pár anotací ve třídách a nic víc neřešíš, funguje to samo

<xkucf03/>

[Josef Kufner]

Ftip je v tom, že z těch několika primitivních typů jsou poskládány ty komplexní. A protože je těm primitivním typům dobře rozumět, není schéma tak důležité, takže se s ním povětšinou nikdo neobtěžuje. Navíc XML ani JSON schema neobsahují žádné sémantické informace a nezvládají složitější validace dat, takže si s tím člověk beztak nevystačí a tak jako tak to skončí u obyčejné dokumentace. I když z té se automatické doplňování nenakrmí, to jo.

S XInclude a dalším zpracováním v parseru, třeba i jen vynecháním komentářů nebo expanze entit, je problém, když chceš dokument načíst, upravit a zas uložit. Jakmile dokument něco takového obsahuje, je velmi těžké až nemožné to při strojové editaci (např. z GUI) zachovat. JSON zde má výhodu v tom, že platí: json_encode(json_decode(string)) == string (až na nevýznamné bílé znaky).

[xkucf03]

Navíc XML ani JSON schema neobsahují žádné sémantické informace a nezvládají složitější validace dat, takže si s tím člověk beztak nevystačí a tak jako tak to skončí u obyčejné dokumentace. I když z té se automatické doplňování nenakrmí, to jo.

V XML Schematu toho uděláš většinu včetně sémantických informací a dokumentace jednotlivých elementů (to ti pak může zobrazovat editor při napovídání podobně jako třeba u Javy zobrazuje JavaDoc). A složité validace můžeš dělat ve Schematronu – tam už ti editor napovídat nemůže, protože to není deklarace očekávaných struktur, ale soubor pravidel, která mají být splněna – dají se jen validovat – takže je dobré kombinovat oboje: co jde, udělat v XSD a ten zbytek ve Schematronu.

S XInclude a dalším zpracováním v parseru, třeba i jen vynecháním komentářů nebo expanze entit, je problém, když chceš dokument načíst, upravit a zas uložit. Jakmile dokument něco takového obsahuje, je velmi těžké až nemožné to při strojové editaci (např. z GUI) zachovat.

To je pravda, je to minimálně hodně kompilované. Ale je potřeba říct, že JSON je v tomhle „lepší“ jen díky tomu, že tuto funkcionalitu nenabízí. Je to asi jako říct: „naše kuchyň je lepší, protože v ní nejsou žádné nože a nemůžeš se pořezat“ – no jo, jenže nemůžu ani krájet. S XML můžeš dosáhnout téhož výsledku, pokud se sám omezíš a nebudeš ty XIncludy používat (případně se smíříš se změněným výstupem nebo napíšeš poměrně složitý program), ale JSON tě takto omezuje nevyhnutelně, nemůžeš si vybrat, zda ano nebo ne, prostě tam ta funkcionalita chybí.

[Josef Kufner]

Ta funkcionalita tam nechybí. Ona tam ani nemá být. Interpretace dat je záležitostí aplikační logiky a aplikační logika nemá v datech co dělat. Pokud se má s daty před načítáním něco stát, je na místě použít preprocesor/generátor, který je předchroupe (zde je pro XInclude, XSLT a podobné věci místo). Tím, že je to ale vestavěné už v parseru, se vše zbytečně komplikuje a aplikace nemá práci s daty plně pod kontrolou.

[xkucf03]

Parsery se dají konfigurovat, zpracování XInclude si můžeš vypnout a řešit si to na úrovni aplikace a mít to plně pod kontrolou. Vtip je v tom, že v XML máš standardizované značky pro vkládání externích souborů, zatímco v JSONu by sis je musel vymyslet – a někdo si vymyslí "include" : "/cesta/k/souboru" a někdo třeba "require" : "file:///cesta/k/souboru"

[Michal Karas]

Ahoj, já bych si k tomu zkusil asi udělat XML Schema/RELAX NG a vyzkoušel v nějakém chytrém javovském IDE, jak se s tím potom pracuje - hlavně co se týče automatického doplňování.

[Jindřich]

na to je atribut xml:lang

[Kit]

Významnou vlastností XML je fakt, že si v rámci aplikace mohu zvolit takové značky, které mi vyhovují. Používání standardizovaných značek je občas výhodné, ale velmi často je silně obtěžující při zpracování.

Dokument XML by měl být vždy tak jednoduchý, jak je to jen možné.

[Jindřich]

To určitě ano, ale proč nepoužít něco, co je součástí specifikace XML 1.0. (Dá se např. očekávat, že některý SW bude na toto připraven.) Zajímavé info zde. Tím Vám ale nic nevnucuji.

[xkucf03]

Variantu A bych použil asi leda v případě, že by jazyky byly pevně dané – tzn. měl bys tam třeba místní název a pak anglický název podle nějakého ISO standardu (např. názvy zemí).

Ve většině případů bych použil variantu B. Jednak nemusíš měnit schéma, když ti přibude nový jazyk. A jednak jsou to generické struktury a můžeš je zpracovávat jednotným způsobem – např. projdeš v cyklu¹ všechny elementy element a jazyk je jen jejich atributem.

V případě A bys musel mít v programu/šabloně vyjmenované všechny jazyky (názvy elementů) a ty zpracovat v cyklu. Nebo bys mohl zpracovat v cyklu všechny (*) elementy uvnitř element bez ohledu na název těch elementů (název bys interpretoval jako hodnotu – jazyk), což taky jde, akorát to má nevýhodu, kdybys tam chtěl vnořit na stejnou úroveň ještě jiné elementy, které nejsou jazykem, ale obsahují třeba nějaké společné informace – tak je nemáš jak odlišit od elementů obsahujících jazykové verze – leda šoupnout do jiného jmenného prostoru.

Nakonec se dá použít oboje. Akorát v případě B můžeš mít i volnější schéma – povolíš element element a atribut lang, ale už nebudeš omezovat jeho hodnoty. V případě A bys to mohl taky udělat takto volné (povolit libovolné elementy uvnitř element) ale pak už bys ve schématu nemohl definovat vnitřní strukturu těchto libovolných elementů – což v případě B můžeš, např. to bude nějaký značkovací jazyk nebo prostý text vyhovující nějakému regulárnímu výrazu atd. No vlastně ve Schematronu by asi i tohle šlo Ale fakt bych spíš doporučoval to B.

_{[1] nebo na ně aplikuješ XSLT šablonu}

[Kit]

V určitých extrémních situacích může mít význam i další varianta zápisu

<element cs="Cesky text" en="Anglicky text" fr="Francouzsky text"/>

[potato]

Frameworkoví puristi teď budou prskat, ale po praktických zkušenostech si myslím, že nejlepší je mít každý překlad v samostatném dokumentu.

[xkucf03]

Zejména když část položek bude překládaných a část společných, že?

Když už to roztahat po víc souborech, tak aspoň použít gettext – k tomu existuje řada nástrojů, které pomohou překladatelům.

To bych ale dělal jen když tam toho překládání bude hodně a bude potřeba ho různě aktualizovat, přidávat překlady atd. – pokud je to pár položek, tak bych to nechal v jednom XML.

[potato]

Pár položek je samozřejmě jiná věc, mluvíl jsem o zkušenostech s věcmi velikosti knihy. Společné obrázky, tabulky, rovnice, ... se dají xincludnout. A běžná situace, kdy nespolečné části obsaují teoreticky společné části, které ale mohou obsahovat malé nespolečné kousky, nemá AFAIK pěkné řešení v žádném hierarchickém modelu.

[xkucf03]

Proč ne? Prostě si jen ty části (elementy) označíš příznakem[což nemusí být jen jazyk, můžeš mít i různé další pohledy na ta data – třeba stručnou a plnou verzi] a pak si vyfiltruješ (třeba XSL šablonou to jde hezky) ty společné části + části s daným příznakem a vytáhneš si z toho třeba českou stručnou verzi.

Tady bych doporučil použít ten obalový element kolem těch alternativních verzí/hodnot – pak se dá líp uhlídat, abys měl všude potřebné varianty (všechny jazyky) nebo měl aspoň jednu jako výchozí (např. když chybí český překlad, vypíše se aspoň anglický text + nějaké varování, že tohle ještě není přeloženo).

[potato]

Co si označím příznakem? Ve chvíli, kdy to je v jazykově rozdělené části, tak už tam mám tu vnořenou skoro-společnou fyzicky několikrát (nebo xincluduji/entituji/...).

Vypsat varování, že to není přeloženo, je typický informatický přístup. Ve skutečnosti ale není cílem libovat si nad procesem, ale dát lidem dokumenty, které jim k něčemu budou a budou dávat smysl samy o sobě. V nich je možné, aby třeba namísto dvou posledních odstavců jedné sekce a dvou dalších někdo napsal jednu stručnou, než se dostane k tomu přeložit to pořádně...

[xkucf03]

Ve chvíli, kdy to je v jazykově rozdělené části, tak už tam mám tu vnořenou skoro-společnou fyzicky několikrát

Tak jsi to asi jazykově rozdělil na příliš vysoké úrovni, je to potřeba dělit opravdu až tam, kde se liší ty texty. Ale dovedu si představit i případ, kdy to nepůjde: některé kapitoly budeš mít jen v některých jazykových verzích, pak to musíš jazykově rozdělit výš, ale zase někde uvnitř budou společné části – to bych pak řešil buď tím XIncludem nebo odkazem na ID v jiné části dokumentu (a tam opět můžou být některé části označené příznakem pro určitý jazyk).

[Kit]

To je bezvadné řešení v případě, kdy zdrojový dokument je jeden se všemi jazyky a zmíněné překlady vzniknou jeho kompilací. Výběr jazyka aplikace se tím zjednoduší na výběr souboru.