Autor Zpráva
jozob
Profil
Na Webylone sa uvádza, že pomocou CONCURu je možné spojiť dva rôzne SGML dokumenty rovnako ako pomocou menných priestorov. Jirka Kosek ale píše, že pomocou CONCURu je síce možné označkovať dokument paralelne, ale pri spracovaní je možný vždy len jeden pohľad na značkovanie. Ján Angelovič píše v podstate to isté.

Ako je to teda? Bol by som rád, keby sa vyjadril aj Chamurappi.

PS: sorry za zvolenú tému, ale mal som dva dôvody:
1) téma SGML tu nie je,
2) predpokladám, že Chamurappi sleduje túto tému pozornejšie ako ostatné.
Chamurappi
Profil
Z mého vyjádření se vyklubal článek. Živoucí CONCUR.
jozob
Profil
Chamurappi
Opět pěkný článek. A MuLaX je zajímavý.
Jirka Kosek
Profil *
Byl jsem vyzván k reakci, tak mi asi nic jiného nezbývá ;-)

Mulax je hezký návrh, ale takových existuje několik -- pamatuji si, že s novým návrhem nějakého paralelního značkování přijde někdo tak každé dva roky. V podstatě se vždy jedná o to, že se vezme Nelsonova myšlenka Xanadu (jeden obsah a nad tím několik paralelních vrstev se značkováním) a naroubuje se to na syntaxi XML, nebo nějakého skoro XML.

Z článku mi připadá, že Chamurappi asi standard SGML nečetl, můžu mu ho zapůjčit. Alespoň tam zjistí, že jeho interpretace toho, co by CONCUR mohl a nemohl, jsou jeho fantazie, standard o ničem takovém nemluví. Podle standardu umožňuje CONCUR jen paralelní označkování dokumentu. Nic víc, nic míň.

Kdyby se CONCUR použil místo jmenných prostorů třeba k tomu, aby se do stránky v HTML vložily vzorce v MathML, může se na dokument člověk dívat buď jako na samotné HTML, nebo na několik MathML vzorců. Standard však nedefinuje vzájemnou interakci obou pohledů, takže nejde zjistit, kde se MathML fragmenty v HTML dokumentu vyskytují -- což je pro správnou interpretaci dokumentu dost problém. Pokud vím ani datový model SGML (grove) nic takového nepodporuje, ale to si mi už opravdu nechce hledat.

Nechci nikoho přesvědčovat, ale SGML je mrtvá technologie (s výjimkou HTML, které se ale stejně většinou zpracovává jako by to ani SGML nebylo). Používá se na několika velkých projektech (military, aerospace, legal), které byly zahájeny dlouho před vznikem XML. To říkám s vědomím toho, že jsem s SGML a navazujícím technologiemi (zejména DSSSL) několik let pracoval a že z pohledu funkčnosti a flexibility bylo XML v některých věcech krok zpátky. Nenapadá mě však nic, co by dnes šlo s SGML nástroji udělat jednodušuji a rychleji než s těmi založenými na XML. Těch nástrojů jsou mraky a jsou mnohem lepší než ty z dob SGML. Ukažte mi RELAX NG pro SGML, XPath a XQuery pro SGML, ... To jsou technologie, které jsou nejméně o kategorii lepší a použitelnější než ekvivalenty z dob SGML.

Ale chápu, že se na ty argumenty těžko přistupuje, když je člověk z principu v opozici.

BTW, minulý týden jsem osobně mluvil s "tím Timem", takže je jasné, že už jsem také nakažen virem W3C a měl bych být okamžitě zlikvidován. Resistance is futile. :-D
Chamurappi
Profil
Reaguji na Jirku Koska:
s novým návrhem nějakého paralelního značkování přijde někdo tak každé dva roky
Ano, našel jsem jich spoustu, pěkný souhrn o nich sepsal Andreas Witt (je to PDF). MuLaX jsem vytáhl na světlo právě kvůli tomu, že užívá CONCUR.
Jinak ta obhajoba paralelního značkování je v mém článku spíše pro zajímavost. Byla to vhodná příležitost rozpovídat se o křížení elementů, které mnoho lidí považuje obecně za neobhajitelnou chybu.

Z článku mi připadá, že Chamurappi asi standard SGML nečetl
Přiznávám.

Alespoň tam zjistí, že jeho interpretace toho, co by CONCUR mohl a nemohl, jsou jeho fantazie, standard o ničem takovém nemluví.
Jistě. Říkám pouze, že v zájmu vyšší kompatibility bylo možné využít syntaxi CONCURu. Podobné fantazie mají i autoři MuLaXu.

Standard však nedefinuje vzájemnou interakci obou pohledů, takže nejde zjistit, kde se MathML fragmenty v HTML dokumentu vyskytují
Pokud ji nedefinuje, neznamená to, že místa výskytu zjistit nejde. MuLaX (jakožto podmnožina SGML) ukazuje, že to jde. Interakci je možné dodefinovat.

Nechci nikoho přesvědčovat, ale SGML je mrtvá technologie
Ano, o tom se nepřu. Zrovna v této věci naivní nejsem.

s výjimkou HTML, které se ale stejně většinou zpracovává jako by to ani SGML nebylo
Většina parserů sice má propracované postupy na řešení chyb, ale tím se standardu SGML nijak neprotiví. Nebo snad ano?
Jiná věc je, že jejich implementace SGML je neúplná (třeba minimalizaci atributů umí jen napůl) a že SGML deklarace pro HTML od W3C nikdy neodpovídala realitě.

Používá se na několika velkých projektech (military, aerospace, legal)
V ČR tuším stále SGML používá Český národní korpus.

z pohledu funkčnosti a flexibility bylo XML v některých věcech krok zpátky
Omezení rozmanitosti SGML chápu, některé jeho možnosti jsou na implementaci vcelku šílené (zejména DATATAG). Můj článek se pozastavuje nad vynalézáním vynalezeného.

Ukažte mi RELAX NG pro SGML, XPath a XQuery pro SGML
Znám jeden nástroj, který umí validovat HTML dokumenty proti schématu v RELAXu NG. Myslím, že vy ho znáte také :-)
Kdyby nabízel SGML parser stejné API jako XML procesor (což mu patrně nic nezakazuje), bylo by RELAXu NG, XPathu i XQuery úplně jedno, že ve skutečnosti pracují nad SGML. Zmíněné technologie potřebují ke své činnosti zejména stromovou strukturu s elementy a atributy, nikoliv správně sestavený XML řetězec. O syntaktické drobnosti, jako jsou SHORTTAG/OMITTAG v SGML nebo třeba i obecné/znakové entity v XML, se nezajímají. Nemusíme zůstávat u drobností: kompaktní syntaxe RELAXu také není well-formed XML, zrovna tak N3 syntaxe RDF.

Těch nástrojů jsou mraky a jsou nejméně o kategorii lepší a použitelnější než ekvivalenty z dob SGML
Ano, většinou jsou. Je jiná doba, vývoj pokročil. Kdyby XML neexistovalo, dříve či později by se použitelnější technologie vynalezly pro SGML (nebo pro jiný jazyk s ambicí SGML nahradit).

<![IGNORE[
Ale chápu, že se na ty argumenty těžko přistupuje, když je člověk z principu v opozici.
Tak. A už jsem zase jen zaujatý krvežíznivý blázen, kterého by nikdo neměl poslouchat, protože je z principu proti všemu správnému. Nejste naopak z principu v opozici vy?
V říjnu 2004 vás mnoho lidí zařadilo do podobné škatulky jako nyní řadí mě. Bylo jim vcelku jedno, co ve svém článku na Intervalu píšete. Nehledali, co se snažíte říct, hledali někoho v opozici -- někoho, kdo z principu (nezáleželo jakého) vyjadřuje přesně opačný názor, než jejich oblíbení dogmatici. Vaši větu „nabídka elementů je zkrátka pořád stejná“ část z nich dodnes označuje za lež a zbytek se tváří, jako by neexistovala.

minulý týden jsem osobně mluvil s "tím Timem"
Ano, vím, Tim měl pár dobrých nápadů, co všechno by mohl validátor kontrolovat. Třeba by se mohl zaměřit i na kontrolu nastavení výchozího stylovacího jazyka pro atributy style, což sám praotec Tim na svém webu nemá.

je jasné, že už jsem také nakažen virem W3C
Lidstvo přežilo už i horší pandemie.

měl bych být okamžitě zlikvidován
Máte štěstí, drakonismus nepraktikuji.

Resistance is futile. :-D
My mind to your mind. Your thoughts to my thoughts.
]]>

Na závěr pár dotěrných otázek:
1) Splňuje CONCUR podmínky pro to, aby mohl být označen za „celosvětově škálovatelný systém zabraňující kolizi v pojmenování elementů“? Pokud ne, v čem je háček?
2) „při zpracování dokumentu je dostupný vždy jen jeden "pohled" na značkování dokumentu, ostatní se ignorují“ -- přikazuje toto SGML standard?
3) Kdyby W3C místo <prefix:name/> použilo <(prefix)name/> a místo xmlns:prefix="uri" použilo <!doctype prefix public "fpi">, čemu by tím ublížilo? Staly by se jmenné prostory méně použitelné?
Jirka Kosek
Profil *
Jiná věc je, že jejich implementace SGML je neúplná
No právě :-(

Pokud ji nedefinuje, neznamená to, že místa výskytu zjistit nejde. MuLaX (jakožto podmnožina SGML) ukazuje, že to jde. Interakci je možné dodefinovat.
No já bych MuLaXu neříkal podmnožina SGML, protože pro vzájemné zjištění polohy fragmentů je potřeba použít speciální datový model, který jde nad rámec datového modelu SGML, což mimo jiné znamená, že pro zpracování nejde použít klasické SGML nástroje, ale jen ty, které rozumějí datovému modelu MuLaXu.

Kdyby nabízel SGML parser stejné API jako XML procesor (což mu patrně nic nezakazuje), bylo by RELAXu NG, XPathu i XQuery úplně jedno, že ve skutečnosti pracují nad SGML.
Znáte to, kdyby byly ryby...

Kdyby XML neexistovalo, dříve či později by se použitelnější technologie vynalezly pro SGML (nebo pro jiný jazyk s ambicí SGML nahradit).
Ne, pro plnohodnotné SGML byl malý trh na to, aby zaplatil vývoj těchto technologií. Už v první polovině 90. let mnoho firem používalo vlastnoručně ořezané verze SGML (žádné DOCTYPE, fixní SGML deklarace) a XML tuhle praxi v podstatě jen sjednotilo a kodifikovalo.

Nejste naopak z principu v opozici vy?
Jistě ;-)

1) Splňuje CONCUR podmínky pro to, aby mohl být označen za „celosvětově škálovatelný systém zabraňující kolizi v pojmenování elementů“? Pokud ne, v čem je háček?
Každý pohled má při použití CONCUR svůj vlastní !DOCTYPE a ten může být použít jako unikátní identifikátor. !DOCTYPE se však v SGML používá pro identifikaci typu dokumentu a DTD, což automaticky znamená, že kvůli CONCUR se musíte zabývat nějakými DTD.

2) „při zpracování dokumentu je dostupný vždy jen jeden "pohled" na značkování dokumentu, ostatní se ignorují“ -- přikazuje toto SGML standard?
Standard mluví o paralelních pohledech a o tom, že se zpracovávají vždy samostatně. Vzhledem k tomu, že pomocí CONCUR lze zapsat i překřížené značkování, které nejde mapovat na obyčejný strom dokumentu v pojetí SGML, nedovedu si představit, jak by se CONCUR dokument prezentoval jako celek (pomíjím teď věci jako MuLaX, které si definují vlastní datový model dokumentu).

3) Kdyby W3C místo <prefix:name/> použilo <(prefix)name/> a místo xmlns:prefix="uri" použilo <!doctype prefix public "fpi">, čemu by tím ublížilo? Staly by se jmenné prostory méně použitelné?
Minimálně bychom se nikdy nezbavili !DOCTYPE. Navíc !DOCTYPE je pevně svázané s DTD, což jmenné prostory naštěstí nejsou. Jmenný prostor a schéma jsou dvě zcela odlišné věci. Technicky by určitě jmenné prostory šly na CONCUR založit, ale muselo by se např. říci, že je zakázané překřížené značkování. Jenže se to před 10 lety neudělalo, takže je teď pozdě.

Jmenné prostory také nejsou žádná výhra a mají své problémy. Kdyby se navrhovaly dneska, také by vypadaly trochu jinak.
Toto téma je uzamčeno. Odpověď nelze zaslat.

0