• TwitterRSS
  • Domů na Webylon
  • Blog
  • Živoucí CONCUR

    2. června 2006

    V jedné z mnoha diskusí o XHTML a XML, které mé texty vyprovokovaly, se vyjádřil sám Jiří Kosek. I přes postoj vyjádřený ve svém slavném článku Proč nepoužívám XHTML, který mnoho lidí četlo a malé procento z nich i pochopilo, tato celebrita webdesignu věří v budoucnost XHTML. Prý je to „správná cesta“.

    Na přetřas přišla i otázka SGML vs. XML. Kosek napsal:

    V SGML (a tím pádem v HTML) neexistuje celosvětově škálovatelný systém zabraňující kolizi v pojmenování elementů. Pro XML takový mechanismus existuje v podobě jmenných prostorů.

    — Jirka Kosek, diskuse xhtml 1.0 vs. 1.1

    Timy, poučen mojí Tragikomedií o Normě [K.24], mu oponoval:

    Podle mě existuje i v SGML, alespoň teoreticky, viz CONCUR.

    — Timy, diskuse xhtml 1.0 vs. 1.1

    Čemuž se samozřejmě Kosek bránil:

    CONCUR je něco úplně jiného než jmenné prostory. Pomocí CONCUR můžete jeden dokument několikrát paralelně označkovat (tato paralelní značkování se mohou klidně i křížit), ale při zpracování dokumentu je dostupný vždy jen jeden "pohled" na značkování dokumentu, ostatní se ignorují. Proto ani nejde definovat pravidla pro to, jak do sebe mohou být jednotlivá alternativní značkování začleněna.

    Holt nesmíte všemu hned věřit [K.24].

    — Jirka Kosek, diskuse xhtml 1.0 vs. 1.1

    Čemuž se samozřejmě budu bránit já.

    Jak to tedy je?

    Ano, CONCUR a jmenné prostory nejsou přesně totéž. Nikdy jsem netvrdil, že jsou do puntíku stejné. Účel je ovšem dost podobný. On snad CONCUR není „celosvětově škálovatelný systém zabraňující kolizi v pojmenování elementů“?

    Stejně jako jmenné prostory řeší konflikt pojmenování elementů na úrovni dokumentu pomocí prefixů. Obě techniky zřetelně přiřazují k prefixu identifikátor: jmenné prostory mají URI, CONCUR má formální veřejný identifikátor (ve tvaru „-//W3C//DTD HTML 4.0//EN“ nebo třeba „+//IDN www.webylon.info//DTD ImaginárníML 1.0//CS“).

    Při zpracování [SGML] dokumentu je dostupný vždy jen jeden „pohled“ na značkování dokumentu, ostatní se ignorují.

    — Jirka Kosek

    Domnívám se, že ne nutně. Běžně užívané SGML parsery pravděpodobně nabízely a nabízí jen jeden „pohled“. Nevěřím však, že to tak mají přikázáno ve standardu. V případě XML si také většina aplikací hledí jen jednoho svého jmenného prostoru a ostatní je nezajímá. Až tak velký rozdíl zde není.

    Pomocí CONCUR můžete jeden dokument několikrát paralelně označkovat (tato paralelní značkování se mohou klidně i křížit)

    — Jirka Kosek

    Ano, můžete a mohou. Jmenné prostory křížení neumožňují. Což je jejich malé mínus.

    Z hlediska teoretického: Na křížení elementů není nic závadného. Informace může mít různé významy v různých kontextech. Příklad: mám citaci, pod ní odstavec a chci vyznačit jednu pasáž, která začíná uprostřed citace a končí uprostřed odstavce. Třeba za účelem poukázání na její nepůvodnost ji chci uzavřít do elementu <sprostě-okopírováno>. Ta pasáž je jen jedna, rozseknout ji by byla chyba. Má význam v jiném kontextu než mají citace a odstavce, je to jiná sémantická vrstva, jiný pohled na dotyčná data.

    Zatímco jeden typ dokumentu můžete bez újmy na sémantice zanést do stromové struktury snadno, u kombinace více typů vás může stromová struktura nepříjemně svazovat. Pokusíte-li se je násilím sešroubovat, nevypadá to příliš vábně.

    Z hlediska praktického: Paralelní značkování vyžaduje složitější API. DOM musí být trošku více rozvětvený strom nebo úplně jiná datová struktura. To možná z dnešního pohledu vypadá jako výrazná komplikace, ale na implementaci by to bylo snazší než obecné, znakové a parametrické entity.

    Z hlediska kompatibility: XML mohlo převzít CONCUR a ve svých definicích paralelní značkování dodatečně zakázat, podobně jako zakazuje rozebrat dokument s fatální chybou. Tím by dosáhlo vyšší kompatibility se SGML, jelikož by i právoplatný SGML parser mohl správně porozumět jmenným prostorům. Že se dnes po takové kompatibilitě nikomu nestýská je vedlejší.

    Z hlediska srozumitelnosti: Podívám-li se na ty statisíce stránek s překříženými elementy, řekl bych, že paralelní značkování není nepochopitelné. Naopak ve jmenných prostorech se vyskytuje pár zákeřných chytáků.

    Víte, že v zápisu <html:a href="adresa"> patří element <a> do jmenného prostoru s prefixem html, ale atribut href již ne? Atribut bez prefixu totiž podle specifikace není v žádném jmenném prostoru, ba dokonce ani ve výchozím (neprefixovaném). Mrkněte na následující dokument:

    <?xml version="1.0"?> <html:html xmlns:html="http://www.w3.org/1999/xhtml">   <html:a html:href="tam" href="sem">Hádej, kam tě dovedu</html:a> </html:html>

    Kam míří tamní odkaz, sem nebo tam? Je to každému na první pohled jasné? Ani nejrozšířenější prohlížeče se v odpovědi neshodují.

    MuLaX

    Roztomilé slůvko, že? Za touto zkratkou se skrývá „Multi-Layered XML“, neboli vícevrstvé XML. Jde o nepříliš známý formát, který se sice hlásí ke XML, ale jde víceméně o samostatný metajazyk vycházející ze SGML. Od XML se liší hlavně v tom, že má ve své SGML deklaraci CONCUR zapnuté.

    Formát je to velice zajímavý, angličtiny znalým čtenářům vřele doporučuji k pročtení o něm pojednávající článek Making CONCUR work (odkázaný dokument užívá XML+XSLT, v případě problémů si račte hrábnout pro PDF verzi). Přímo o vztahu CONCURu ke jmenným prostorům se tam píše:

    Na první pohled vypadá koncept anotačních vrstev v MuLaXu a jmenných prostorů v XML velmi podobně. Oba dva rozlišují a vyznačují elementy patřící do různých anotačních schémat. Ale protože dokumenty, které užívají značkování z různých jmenných prostorů, jsou stále hierarchicky strukturované XML dokumenty, problém překřížených struktur přetrvává.

    článek Making CONCUR work

    Jinými slovy: Hlavní rozdíl je skutečně jen v tom překřížení. Účel je stejný. Kdyby samotné XML převzalo CONCUR a jen mu zakázalo překřížení, byly by jmenné prostory zpětně kompatibilní.

    Dotyčný článek mimochodem také pojednává o stavbě objektového modelu vícevrstvého dokumentu a o používání XPathu nad takovou strukturou. MuLaX je tudíž dalším příkladem [K.28] jazyka, který těží z XML technologií, aniž by sám užíval XML syntaxi.

    Těším se na pokračování diskuse a na další reakce.