Názory k článku Proč XML není jen bublina

Myslím si, že je dobré se na věci dívat z jeho kladných i záporných stránek. XML bylo nezřídka zbožšťováno, a nekriticky obdivováno. Přitom je jasné, že XML jakožto technologii má své bílé i černé stránky, jako každá jiná.

Když se objevil článek o tom, že XML není jen paráda a vyřešení všech problémů lidstva, nečekal jsem, s jakou rychlostí se to bude "uvádět na pravou míru". No, ale budiž, určitě je to daleko poctivější snaha o objektivitu, než pouhá glorifikace.

Řekl bych, že tento článek reaguje na něco úplně jiného, než byly ty námitky ;-)

Začal bych něčím OT. Varianta

<a>
<href>http ://www.root.cz/</href>
<name>root.cz</name>
</a>

se mi líbí podstatně víc -- za předpokladu, že nedatlím www stránky v notepadu, ale že jsou to strukturovaná data, která se mají uchovat těch deset let, jak píšete.

Málokdo tvrdí, že XML je úplně k ničemu, a že za chvíli bublina splaskne a nebude ho používat vůbec nikdo. Nicméně XML je momentálně buzzword, XML musí být všude a ve všem, a kdo řekne, že se XML k něčemu nehodí, je v nekterých kruzích zlynčován ;-) Tohle *je* nafouknutá bublina, která splaskne, až čas ukáže kde je XML skutečně výhodné.

Dál není pravda, že nemusím používat všechny ty X* technologie. No, nemusím pravda používat *úplně* všechny. Nicméně musím používat, nebo aspoň vzít v úvahu ty, které používají lidé, organizace a software, s nimiž potřebuji nebo chci spolupracovat. A jak správně popisujete, každý používá něco jiného, takže nakonec si moc nevyberu.

>Dál není pravda, že nemusím používat všechny ty X*
>technologie. No, nemusím pravda používat *úplně*
>všechny. Nicméně musím používat, nebo aspoň vzít v
>úvahu ty, které používají lidé, organizace a
>software, s nimiž potřebuji nebo chci
>spolupracovat. A jak správně popisujete, každý
>používá něco jiného, takže nakonec si moc >nevyberu.

Záleží přece na tom jak chcete spolupracovat. Jestli se jedná o vývoj softwareové komponenty pro jinou firmu tak asi ano, ale pokud si chcete s nejakou firmou pouze vyměnovat informace (ve standartizované formě), tak vám je jedno jestli používají X* nebo mají pronajatých 40 důchodců co to louskají ručně.

Co třeba validace? Já, jakožto zpozdilec, si normálně vystačím s DTD. Nicméně máme XML Schema, Relax NG, XDR, SOX, Schematron, DSD a kdovíco ještě. Když někomu pošlu DTD, tak musí použít k validaci DTD nebo si to do něčeho převést. (DTD je ještě ta nejmírnější možnost, protože je nejstarší, takže funguje všude.)

Validace je volitelný, nikoli povinný krok při čtení dokumentu XML. Takže XML načtete, aniž byste byl nucen dělat validaci, a zajímal se o to, zda je schéma dokumentu popsáno v DTD, RNG, WXS nebo něčem jiném.

Jasně že validaci nemusím dělat. Jenže ji třeba chci dělat ;-) Skutečnost, že ji mohu dělat deseti nekompatibilními způsoby, podle mne naznačuje, že *něco* tu splasknout musí -- netvrdím samozřejmě, že to něco bude ,,core XML``.

"Řekl bych, že tento článek reaguje na něco úplně jiného, než byly ty námitky ;-) "

Samozrejme. Toto je reakce na nektere hlasy tvrdici, ze je XML je vubec cele spatne. K namitkam, ze XML API jsou prilis obtizna, se (tento) clanek temer nevyjadruje a nic "neuvadi na spravnou miru."

Souhlasím, až na optimistický názor, že XML časem splaskne. XML jen tak nesplaskne, řeší totiž dost závažný problém všech programátorů v C, C++, Javě a podobně dementních jazycích, že *nedokáží jednoduše načíst a zapsat data zapsaná v podobě vlastního zdrojového kódu*. To je reálná potíž a XML ji jaksi řeší.

Nic proti tomu že se pokusili definovat nějaké řešení, kdyby to aspoň udělali dobře, tak by mohlo být dobře použito jako "společná řeč". Jenomže použít pro reprezentaci dat formát určený pro zápis formátovaných textových dokumentů?!?! Ještě že si nevybrali nějakou verzi .doc nebo RTF...

Přidám další nedostatek: Kolik práce dá napsat kompletní a validující XML parser? Ad přítomnost atributů: Proč to dělat jednoduše, když to jde složitě, že, tak zavedeme atributy...
..

nedokáží jednoduše načíst a zapsat data zapsaná v podobě vlastního zdrojového kódu

Souhlas. Nebylo by proto lepsi "na to jit od lesa" a zaradit jednoduchy kompilator ANSI C (plus jednoduchy restricted execution/interpreter) do standardni knihovny? Melo by to oproti XML same vyhody a orezany self-compiling prekladac C ma nejake 3kB. http://fabrice.bellard.free.fr/otcc/

Samé výhody? Třeba, že data zapsaná programem v C, by nešla přečíst v Jave a C#? Tomu říkám opravdu velká výhoda :-)

Proc by nesla? Kdyz nekdo tu knihovnu naportuje do Javy a C# tak to pujde precist i tam.. XML taky neprectete bez XML parseru. A co se tyce tech vyhod, tak jsou zrejme:

1. Neni nutne vytvaret novou syntaxi a novy datovy format.
2. Stejny instrument popisuje data i algoritmus.
3. Odpada potreba DTDcek.
4. Validace je vypocetne uplna.

Je to tedy univerzalnejsi, jednodussi a silnejsi nastroj.

No to je mi bomba. Místo jakz takz rozumneho XML budeme data uladat v nejakem demetnim tricet let starem cecku? Me by se treba libilo ukladat data jako zdrojak v Ade95 (a bylo by to mnohem hezci, nez C). To by me zajimalo, jak by to ostatni nacetli. XML je fajn, protoze jde mimo programovaci jazyky.

Nechápu, co jste chtěl říci tím C, C++, Java, ... Jsou to kompilované programovací jazyky. Produktem kompilace je spustitelný program na dané platformě. Zpracování svého vlastního zdrojového kódu je obtížné. OK.

Pak máme interpretované jazyky -- shell, Python, Perl, ... Tam se zpracováním a modifikací svého kódu problém není. Cenou je to, že musí být interpretovány (mno, teda jak kdy, ale to je technický detail).

A XML? XML je značkovací jazyk. Výsledkem kompilace XML je třeba PDF, PostScript, HTML, .... Jakým způsobem bude to PDF zpracovávat svůj zdrojový text, tj. to XML? Nebo jak jste to přirovnání k C myslel?

Nerozumím co myslíte pojmem "kompilované" a "interpretované" jazyky a jaký přesně rozdíl je v tomto smyslu třeba mezi Javou a Pythonem. Co jsem měl na mysli já je kupříkladu přítomnost `exec' v Pythonu a jeho nepřítomnost v Javě. Dělám-li konfigurák pro program v Pythonu, nejjednodušší (byť ne nutně vždy nejlepší) je zapsat ho v Pythonu. Je-li program v Javě, žádnou podobně jednoduchou možnost nemám.

Tohle chápu, ale nechápu tu návaznost na XML.

Napíšu to jednodušeji: XML je jen forma uchování dat, takže skutečnost, že je v XML možné [mimo jiné] zaznamenat aplikaci zpracovávající XML, o ničem nevypovídá. V ASCII také mohu [mimo jiné] zaznamenat aplikaci zpracovávající ASCII.

Trochu jiná věc je zmiňovaný lisp, kde právě není to ,,mimo jiné``.

Jen bych upozornil, že XML != "...formát určený pro zápis formátovaných textových dokumentů?!?! Ještě že si nevybrali nějakou verzi .doc nebo RTF... "

XML je naopak formát určený pro popis struktury dat, nikoli formátování textových dokumentů. Možná by bylo spávnější říci dokonce metaformát/metajazyk, který umožňuje vytvoření vlastního jazyka pro potřeby konkrétního uživatele. Někteří uživatelé si mohou na základě XML vytvořit vysoce strukturované formáty, jiný zase jazyk, který umí zachytit třeba formátování dokumentu -- např. WordML v novém Wordu 2003.

Ale rozhodně nelze XML považovat za jazyk pro zápis formátovaných textových dokumentů.

OT. Tím udělat dobře jste myslel něco na bázi Lispu/Scheme? Ty by jistě také fungovalo, v něčem možná i lépe. Ale k jazykům tohoto druhu má mnoho lidí předsudky, stejně tak, jako mnoho lidí mělo předsudky k SGML, takže se nerozšířily tak masově, jak by si asi zasloužily. U delších dokumentů může být navíc velmi přehledné, když u koncového tagu vidíte, co vlastně ukončujete. Tuhle situaci vám ")" moc neulehčí. Podobnou vlastnost nabízelo SGML v podobě různých minimalizací, které umožňovaly koncový tag úplně vypustit, nebo jej zapsat např. jako </>. Sice je to pořád více než ), ale idea je podobná. Ale úplně životaschopná asi nebyla, když XML až na pár minoritních oblastí SGML zcela vytlačilo.

Možná jsem mimo, ale podle mě XML vychází ze SGML, což je jazyk pro reprezentaci dokumentů. XML chápu jako konkrétní, zjednodušenou, instanci SGML. Tipuji, že kdyby SGML nebylo tak trochu mamut, pro nějž je velmi obtížné napsat parser, XML by vytvořeno nebylo. A obtížnost napsání parseru je podle mě pravý důvod, proč SGML bylo XML vytlačeno, ne to jak konkrétně lze nebo nelze zapsat uzavírací značku.

Pod "udělat dobře" jsem nemyslel nic konkrétního. Stačí cokoliv, co (tolik) netrpí uváděnými nedostatky. *Možná* třeba něco jako YAML -- nestudoval jsem to, tak nevím, ale přinejmenším tam uváděné cíle vypadají rozumně (přičemž XML jich většinu nesplňuje).

SGML je stejně jako XML metajazyk. Můžete si v něm vytvořit vlastní značkovací jazyk pro zápis jakéhokoliv druhu dat -- textových dokumentů, datových struktur, záznamů z relační databáze, vektorových obrázků, chemických vzorců, ...

XML je podmnožina SGML. Z SGML byly odstraněny minimalizace a hlavně byla zafixována SGML deklarace. SGML deklarace sloužila k definici toho, jakými znaky se vlastně tagy uvozují apod. Takže SGML dokument nemusel používat "<" a ">", ale jakékoliv jiné znaky. Tyto vlastnosti byly pravým důvodem (vaším mamutem), proč bylo obtížné napsat parser SGML. V XML proto byly tyto vlastnosti odstraněny, použití DTD je nepovinné a znaková sada je Unicode.

Prosil bych Petra Cimpricha, aby psal vice podobnych clanku (o XML - at uz "pozitivnich", nebo "negativnich"). Diky

souhlas

RE: internacionalizace

To neni tak docela pravda: XML sice obsahuje informaci v jake kodove strance je napsano, ale bohuzel uz napsanou v nejake kodove strance.. tzn. neexistuje zpusob jak zjistit kodovou stranku jeste pred ctenim dokumentu. Nehlede na neexistenci moznosti zapsat cast dokumentu v jine kodove strance.

A cast dokumentu v jine kodove strance bych chtel psat proc? To by ze me parsery asi definitivne zcvokly.

T.

eeeh ? co je to za ptakoviny ?
proc bych si nemohl psat cast dokumentu v jinym kodovani ?
pokud ovsem nekdo neuvazuje o tom cpat diakriticke znaky do nazvu elementu a pod (coz by ovsem byla stejna demence jako cpat diakritiku du nazvu promennych, procedur/funkci/trid/cehokoli, ci dokonce klicovych slov programovaciho jazyku (podle me nepatri diakritika nikam jinam nez do dat a uzivatelskyho rozhrani, maximalne tak jeste do mailu od sefu a dalsich ignorantu).
klidne muzu mit neco typu
<xxx>
<enc1250>cokoliv v cp1250</enc1250>
<enc????>blah blah, cp ????</enc????>
</xxx>
a podle kodovy stranky pod kterou program pojede si vybrat relevantni polozku.

... a odsoudim se k tomu, ze nebudu moci pouzivat 90% dostupnych nastroju - pocinaje text editory, ktere mi od tohoto okamziku nezobrazi cely dokument spravne, ale vzdy jen tu cast se spravnym kodovanim a konce vsemi konvertory mezi kodovacimi tabulkami.

Tohle myslim do xml opravdu nepatri. Od ceho mame unicode, ze?

ja jsem pouze rikal ze ta moznost tu je, ne ze by to mel nekdo delat ....

<joke>unicode je skvela vec, zavedeme si rovnou znaky pro f^n a bl, ne ? nebo pockame do hyper-space-wide-unicode verze s 32B na 1 znak a dostatkem znaku pro vsechny formy zivota v tehdy znamem vesmiru ?</joke>

To prvni tvreni neni tak uplne pravda, podle specifikace muze nazev kodovani obsahovat pouze

[A-Za-z] ([A-Za-z0-9._] | '-')*
/* Encoding name contains only Latin characters */

Pro podrobnosti doporucuji
http://www.w3.org/TR/REC-xml#NT-EncodingDecl

Jezovec

The EncName is the name of the encoding used.

Pokud to dobře chápu, jedná se o NÁZEV kódování, nikoliv o text. Tedy název kódování \"UTF-8\" žádné non-latin characters neobsahuje, ovšem v textu kódovaném v UTF-8 být mohou.

"To neni tak docela pravda: XML sice obsahuje informaci v jake kodove strance je napsano, ale bohuzel uz napsanou v nejake kodove strance.. tzn. neexistuje zpusob jak zjistit kodovou stranku jeste pred ctenim dokumentu."

Jeste pred ctenim dokumentu jiste ne :)
XML ma pouze mechanismus, jak z nacteni nekolika prvnich bajtu jednoznacne urcit kodovani a znakovou sadu celeho dokumentu, aniz by predem byla znama. Funguje to prinejmensim pro Unicode a vsechny kodove stranky rozsirujici ASCII.

"Nehlede na neexistenci moznosti zapsat cast dokumentu v jine kodove strance."

K tomu jsou externi entity.

>Jeste pred ctenim dokumentu jiste ne :)

Mel jsem na mysli to, ze musite precist cast dokumentu UZ V URCITEM KODOVANI abyste zjistili ahaaa, je to kodovani to a to. Ano, funguje pro ASCII, ale uz ne pro Unicode ( LE,BE), pouze pro Utf-8, ale hlavne ne pro EBCDIC atd

>K tomu jsou externi entity
Cekal bych, ze my takovy format umozni napsat slovnik, treba Japonsko-Cesky, kde jednoznacne potrebuji dve zcela odlisna kodovani

nerikam ze xml je shit, rikam ze xml je bohuzel shit

Nejak mi unika smysl, proc pouzivat vice kodovani v jednom dokumentu. Konkretne k tvemu prikladu by ti stacila UTF16, ktera pokryje oba jazyky.

Myslim ze jde rozponat minimalne UTF-8 a UTF-16, LE i BE. EBDIC asi vazne neprojde.

http://www.w3.org/TR/REC-xml#charencoding
"Entities encoded in UTF-16 must begin with the Byte Order Mark described"

Mimochodem vis o lepsim zpusobu rozpoznavani kodovani?

Tin

"Ano, funguje pro ASCII, ale uz ne pro Unicode ( LE,BE), pouze pro Utf-8, ale hlavne ne pro EBCDIC atd "

Mam za to, ze Unicode ma byte-order mark pro rozliseni UTF8/16 a LE/BE. S EBCDIC bohuzel nemam zkusenosti. Urcite existuji systemy, kde se autodetekce nepovede, ale presto se domnivam, ze se XML k i18n stavi celem.

A japonsko-cesky slovnik bych, kdybych umel japonsky, pohodlne napsal cely v Unicode. Spis bych mel problemy s fonty a editorem, nez jak to ulozit do XML.

A on se EBCDIC jeste nekde pouziva? Za meho mladi si konkuroval s ASCII, ale mel jsem dojem, ze za tech celkem dost let ho ASCCI spolehlive pobil.

Obcas se s tim setkam na IBM, treba v bankach to jeste pouzivaji.

XML kodovani - funguje to takto (pokud si to dobre pamatuji), ze:
- prectenim prvnich par bytu zjistis urcite pocet znaku na znak a mozna kodovani
- jakmile znas pocet znaku na znak, tak neni problem zjistit si z hlavicky kodovani

Kdo nedela v XML, ten neni programator. Proc vyuzivat databaze SQL na to, na co jsou urceny?
Ukladejte XML do jedineho BLOBU!!!
<Mnoho_povyku_pro_nic> rekl bych.

To mi pripomina rozhovor na Linuxu, kde se na nas obratil jeden pan a chtel doporucit editor XML, ktery by automaticky kontroloval DTD a kdo vi co jeste a kdyz jsem zjistoval na co to chce, tak jsem zjistil, ze vubec nepotrebuje editor XML, ale databazi a servrovou aplikaci. No myslim, ze si to stejne nedal vymluvit a dnes ma x licenci za x$ spickoveho profesionalniho XML editoru aby mu v tom zamestnanci rucne busili XML a jedine co tim ziskal je kontrola gramatiky podle DTD. Jo, XML je zkratka moda.

Ne na Linuxu, ale na Invexu, uz me ten Linux leze vsude a to jsem to po sobe precetl.

No jestli narazis na Oracle tak to je fakt hustej humus. Nasrat tam XMLType coz je v dusledku CLOB obalit to silenym humusem v podobe DBMS_XMLDOM DBMS_XSLPROCESSOR atd ... myslim ze se Edgar F. Codd obraci v hrobe ... Manazeri ctou CHIP a prichazej s myslenkama ze 720 milionu rekordu ulozej do XML protoze to Oracle umi :-)))). Lidi copak vam nevadi ze vypocetni vykon/propustnost procesoru roste ale vysledny vykon systemu spis klesa. Diky shitum like XML,Java,Python atd ... Pritom jediny co funguje je napsany v C/C++. Az mi nejakej borik ukaze Operacni system napsanej v Jave a na nem mu pobezi browser napsanej v Pythonu tak to bude bomba ...

XML pro vymenu dat proc ne i kdyz si nemyslim ze je to nejaka vyhra. Ono CSV ma taky neco do sebe a parser na CSV napise kazda lama v C za 5 minut. Bude to rychlejsi, nesezere to tolik mista na disku. Vim o cem je rec. Jelikoz jsem nechtel byt kverulant co nadava na XML aniz by nevedel o cem je rec. Tak jsem precetl nekolik tisic stranek dokumentace o XML,DTD,DOM,SAX,XSLT o integraci XML do Oracle DB a provazanosti techto technologii a jestli nekomu pripada parsovani XML dokumentu pomoci DOMu napriklad v PL/SQL v Oracle jako dobrej zpusob jak si vymenovat data tak tenhle svet fakt jde do ......

Howg ...

Jo java je sqela vec ...
inicializace JVM
1) kolik mame pameti 5GB ? Hmmm vemem si 300MB pak zacnem zrat co to pujde vsak tu pamet sezerem
2) kolik mame procesoru 8 hmmm zatizime hned jeden na ostatni se dostane casem ...
3) coz takhle ukladat .java do .xmljava bude prehlednejsi kod :-)))))


Bye :-))

XML důsledně a od začátku NEpoužívá Unicode ale jekýkoliv kódování který je uvedeno v hlavičce. První parsery ať už ms xml nebo apache neuměli unicode vůbec, pouze utf8.

>>V XML je možné reprezentovat prakticky cokoli.
To v binárním souboru taky a mnohdy lépe, protože pro binární data se nemusí převádět na base64 nebo hex.

>>Interoperabilita
stačí se podívat na soap, kdy dva systémy tvrdí že jedou v soap a nerozumí si, protože jeden má soap:Envelope a druhý env:Envelope.

>>Chcete-li, aby vaše informace byly použitelné ještě za deset nebo více let, je jejich uložení v XML patrně tím nejlepším, co můžete udělat.
Tohle vždycky tvrdí reklama A i reklama B. Pokud nebudu mít za 10 let popisný soubor jak s tímhle xml naložit, co který tag znamená, je mi překrásně formátované xml naprt stejně tak jako nezdokumentovaný binár. Ale pokud xml slouží pro zápis položek typu jméno a příjmení (z nichž je jasné o co jde) pak to bezesporu přečíst půjde. Jenže stačí aby autor xml nazval tag místo jméno NM a příjmení AX a už víte taky houby.

>>Validace
Je u xml potřebná zatímco u binárního souboru většinou není třeba. Validace je časově náročná jednak na sestavení (XSD) a na provedení. Nehledě na krásný prvek organizace w3c, že definici XSD mění (nedoplňuje ale opravdu mění) každou verzi.
U binárních dat má každá položka svoji délku a místo.

To co je u xml neustále vytahováno jako obří výhoda je internacionalizace a flexibilita či spíše univerzálnost. To první rozhodně ano, ale pokud nejsem rozumu mdlého a potřebuju data spravovat v různých kódováních, pak i u binárních dat není nic snažšího než je ukládat v unicode (mimochodem i unikódů existuje nejméně 5 variant). Univerzálnost bych nebral moc jako výhodu, neb cokoliv univerzálního je vesměs těžší na zpracování což vede k degradaci výkonu, ke zvětšování šířky přenosového pásma a k potřebě vetší kapacity úložného prostoru.

Počítačem zpracovávaná data MUSÍ být uzpůsobeny počítači a ne uživateli počítače a obráceně. Jinak to vede k neefektivnosti zpracování.

Bohužel se z XML stala modla vedoucích pracovníků, kteří nyní nechápou, jak se mohli bez tohoto formátu tak dlouho obejít, zatímco pro programátory se stává noční můrou.

Ad Unicode:

UTF-8 je Unicode (ve smyslu instance, to jest UTF-8 je jednou z jeho representací), takže tvrzení, že něco neumí vůbec Unicode, ale umí UTF-8, je protimluv.

Nejsou žádné ,,varianty`` Unicode (pomineme-li Unicode vs. ISO-10646-1). Jsou pouze verze, a ty jsou zpětně kompatibilní. Pokud variantami myslíte representace (UTF-7, UTF-8, UTF-16, UCS32, ...), tak převod mezi nimi je triviální, srovnatelný s převodem LSB <-> MSB (když už došla řeč na binární data).

To byla samozrejme blbost, dobre mi tak. Mineno bylo ze prvotni xml parsery nebyly schopny precist utf-16, z kolekce unikodu pouze utf-8.

Mimochodem variant znamena promenny - jadro unikodu je stejny jenom vysledek je trochu jinej :)

To byste se divil, že UTF-8 a Unicode umí totéž!
Teoreticky možná, ale prakticky by se žádný červ bez chybně implementované transformace neobešel. - A stejně bude nejspíše časem i XML rájem pro hackery.
Jen tak dál, čím složitější, tím snáze prorazitelnější (protože v implementacích bude chyb jak máku.)

"stačí se podívat na soap, kdy dva systémy tvrdí že jedou v soap a nerozumí si, protože jeden má soap:Envelope a druhý env:Envelope."

Co s tim ma spolecneho XML samotne? XML nemuze za nekompatibilitu reseni nad nim postavenych. Muzete zrovna tvrdit, ze kremik je z hlediska kompatibility docela osemetna zalezitost, *protoze* nad nim stoji nekompatibilni MS Wordy.

Interoperabilita (fuj) XML je IMHO treba v tom, ze se nemusim zajimat o endianitu, o bitovou sirku cisel, muze mi (na aplikacni urovni nad parserem) byt putna, v jakem kodovani puvodni XML soubor je; muzu relativne snadno (sablonou) prevest jeden XML soubor na druhy...

[validace] "Je u xml potřebná zatímco u binárního souboru většinou není třeba."

Delate si legraci? Jde o to, ze nektere vstupy zkratka *je* potreba validovat. Protoze jsou to veci, ktere ma nepritel otevrene k disposici, protoze je k disposici mit musi. Konfiguracni soubory, requesty, ... Jak potom chcete obecne validovat ta slavna binarni data?

"Univerzálnost bych nebral moc jako výhodu, neb cokoliv univerzálního je vesměs těžší na zpracování což vede k degradaci výkonu, ke zvětšování šířky přenosového pásma a k potřebě vetší kapacity úložného prostoru."

V jistych pripadech jsou zkratka universalni reseni jednoznacnou vyhodou. Prenosove pasmo se o sebe postara samo (transparentni (de)komprese) a jestli se bojite, ze Vam disk zaplni XML soubory...

"Bohužel se z XML stala modla vedoucích pracovníků, kteří nyní nechápou, jak se mohli bez tohoto formátu tak dlouho obejít, zatímco pro programátory se stává noční můrou."

Jojo, zlate doby psani vlastnich parseru pro konfiguracni soubory, comma separated value soubory, zlate doby parsovani cizich binarnich formatu!

T.

Soap byl pouze jako jeden z prikladu, kdy xml-based data si spolu nerozumi nikoliv jako pohana soapu (no i kdyz :).

No jo, s tou validaci jsem ujel.

>>V jistych pripadech jsou zkratka universalni reseni jednoznacnou vyhodou.
To nepochybne, ale nesmi se to prehanet.

>>Prenosove pasmo se o sebe postara samo (transparentni (de)komprese)
Jenze kompr/dekompr stoji nejakej strojovej cas. Pri nekolika pristupech za minutu nepoznate nic, ale pri 10000 je to uz pekne znat. I kdyz zalezi taky na kompresi.

a jestli se bojite, ze Vam disk zaplni XML soubory...
Jeden muj zakaznik ma soustu souboru v excelu a mnohdy vic nez 4 MB na soubor. A kdyz totez bude v xml tak to bude neco k 15 MB na soubor. Muzete namitnout ze mit takovej rozsah v excelu je kravina (coz mu bylo nekolikrat predlozeno), jenze je to jeho volba a hotovo.

XML je zajimavej format, ale nelze jim resit vsechno.

>>jeden muj zakaznik ma soustu souboru v excelu a mnohdy vic nez 4 MB na soubor. A kdyz totez bude v xml tak to bude neco k 15 MB na soubor.

Videl jste nekdy OpenOffice? Ten to ma ulozeno v zazipovanem XML. A jak malo mista to zabira (ve srovnani s MS Office).

Nedokazu si odpustit par komentaru:

"XML důsledně a od začátku NEpoužívá Unicode ale jekýkoliv kódování který je uvedeno v hlavičce. První parsery ať už ms xml nebo apache neuměli unicode vůbec, pouze utf8."

Dulezite je, co rika specifikace XML 1.0, ne jak funguje/fungoval MSXML. Znakova sada Unicode/ISO/IEC 10646, at uz kodovana jako UTF-8 nebo UTF-16, je pro XML od zacatku primarni znakova sada.

">>Interoperabilita
stačí se podívat na soap, kdy dva systémy tvrdí že jedou v soap a nerozumí si, protože jeden má soap:Envelope a druhý env:Envelope."

SOAP nema co delat se syntaktickou interoperabilitou XML. A zpackane implementace SOAPu uz vubec ne.

">>Chcete-li, aby vaše informace byly použitelné ještě za deset nebo více let, je jejich uložení v XML patrně tím nejlepším, co můžete udělat.
Tohle vždycky tvrdí reklama A i reklama B. Pokud nebudu mít za 10 let popisný soubor jak s tímhle xml naložit, co který tag znamená, je mi překrásně formátované xml naprt..."

Pokud ten popisny soubor bude napr. v DocBooku, jste v pohode :)

">>Validace
Je u xml potřebná zatímco u binárního souboru většinou není třeba. Validace je časově náročná jednak na sestavení (XSD) a na provedení."

Spousta lidi se bez validace prekvapive casto obejde. A pak, validovat proti DTD nebo RNG neni az tak narocne.

"Bohužel se z XML stala modla vedoucích pracovníků, kteří nyní nechápou, jak se mohli bez tohoto formátu tak dlouho obejít, zatímco pro programátory se stává noční můrou."

Pokud vas vedouci pracovnik nuti validovat s XSD, mam pro tu averzi pochopeni. S uctou programator, pro nehoz XML neni nocni murou.

K většině vašich připomínek se již vyjádřili ostatní. Dovolím si jen jednu poznámku:

"Nehledě na krásný prvek organizace w3c, že definici XSD mění (nedoplňuje ale opravdu mění) každou verzi."

XSD mají jen jednu verzi, a to 1.0. Jestli jste pracoval s drafty XSD, je celkem jasné, že se měnily. A v každém takovém dokumentu je jasně napsáno, že to je jen návrh, který se může kdykoliv změnit. Takže postavit na tom aplikaci, která se pak musí předělat s každým novým draftem nebo finální verzí, je problém toho, kdo se rozhodl použít za základ aplikace technologii, která se teprve standardizuje.

tady nekdo napsal neco jako "formaty dat musi byt prizpusobene pocitacum a ne lidem"

tak tohle je vazeni opravdu velka a navic zastarala kravina

tak to mozna mohlo byt pred X lety, ale dnes se musi pocitace (vcetne formatu dat) holt prizpusobovat lidem

To sem byl ja, kdo to rekl.
Musite rozlisovat data ktera jsou urcena pocitaci a nikoliv uzivatelum. Je jasny ze data, do kterych leze i uzivatel, musej bejt uzpusobeny jemu. Je na pytel, kdyz vyvojovy nastroje ukladaj zdrojaky binarne, treba powerbuilder, nebo jeste nedavno Delphi 5 formy.
Jenze kdyz potrebujete od compu nejakej vykon, tak proc mu to ztezovat.
Nedovedu si predstavit databazi jako oracle postavenou nad xml a nikoliv nad binarem.

Tak to já si ji představit dovedu.
Horror, že by Hitchcock s jekotem zdrhnul.
Pochopitelně ne, pokud někdo potřebuje uložit pár set výsledků z koňských dostihů. Ale když máte miliony záznamů a potřebujete k nim v reálném čase... To i SQL často zdržuje a člověk má cukání, že by to přece šlo...

Tohle platí, když jde o tu stranu "ven" - k uživateli. Když si povídají procesy, jde to taky, ale ale dře to.

Zažil jsem naprosto strašný případ. Šlo o propojení jakéhosi externího zdroje dat s naším žroutem. On vše kódoval do XML. Takže pár dat se zakódovalo, přeneslo, dekódovalo, dvoubajtový integer pochopitelně do 5 znaků, <blablabla> před </blablabla> za...
Furt ještě žádná hrůza. Jenže po nás se chtělo, aby to bylo rychlý! A když říkám rychlý, tak se chtělo fakt rychlý!
No, udělat to šlo, ale rychlý to nebylo ani náhodou. Nakonec bylo jednodušší vysvětlit a dokázat manažerům, že to, co zdržuje není naše část. Kdo někdy něco takového šéfům vykládal, pochopí, ostatním vyložit nelze.

Na něco jsou zkrátka proprietální binární formáty nenahraditelný. Je s tím víc práce, ale někdy to jinak nejde. Stejně jako když potřebuju opravdu rychlost, tak jdu do C nebo assembleru.

To máte jako se zavírací kudlou se spoustou želízek. Může se hodit, ale buď to nebude ani pořádná kudla, ani šroubovák, nůžky, vývrtka a padesát jinejch bazmeků, nebo to bude vážit tak 3 kila a urve vám kapsu.

Ale na strukturování textu, zápis masivně nehomogenních dat, údajů, u kterých prostě od začátku nemůžete strukturu znát detailně, tam XML patří.
Nahrazovat jím relační DB, je blbost. Nehospodárná a zbytečná blbost.

Ad rychlost čtení XML. Existuje mnoho parserů, a některé jsou rychlejší a některé pomajelší. Mnohdy jde aplikace, které se starají o zpracování velkého množství zpráv v XML, výrazně zrychlit použitím rychlejšího parseru.

Většina XML parserů je dnes psána tak, že se parser ručně naprogramoval. Existují však parsery automaticky vygenerované pomocí nástrojů jako bison/flex a jsou několikrát rychlejší než klasické parsery. Mají třeba omezenou funkčnost -- neumí validovat, nedoplňují defaultní hodnoty atributů,zahazují komentáře apod., ale v kontrolovaném prostředí nemusí vadit, že parser podporuje jen podmnožinu XML.

To je fajn. Ale když 1) jsem skutečně v kontrolovaném prostředí a 2) potřebuju skutečně rychle něco předávat, tak zdržuje každý parser.
Žádný parser bude vždycky rychlejší. Už jen převod integer-string-integer zdržuje. Stejně musí parser vyhledat úvodní tag, koncový tag, zjistit, jestli to má převádět nebo nechat tak...
I ta kudla může být švýcarská s křížkem, takže lepší než většina jiných krámů. Ale pořádnej pajzák to stejně nikdy nebude.

To, co jsem uváděl, je podle mě právě příklad toho, kam XML neé. Což neznamená, že na jiné věci by se XML nehodilo. Bublina to není, nesplaskne stejně jako nesplasklo ASN.1.
Když jsem kdysi študoval databáze, byla tam zmínka o vojenských, heterogenních DB, kde se pracuje s proměnnou délkou věty. XML podle mě ideální řešení.

Tedy, mám přesně takovou kudlu a slouží
mi výborně ;-). I ten křížek má. Jediné
želízko, které jsem zatím efektivně
nepoužil, je pilka. A zatím nemám tolik
nepřátel, abych potřeboval pořádný pajzák :-)).

XML je dobre na prenaseni i skladovani dat, pokud se umime shodnout na jejich semantickem vyznamu. To ale neznamena, ze nemuze byt nic lepsiho nebo aspon stejne dobreho. XML je vsak standard a spousta lidi se ho rozhodlo pouzivat, proto by bylo dobre se spis zamyslet nad tim, jak si praci s nim co nejvice zjednodusit.

Na druhou stranu je to i buzzword, ktera dokaze vytvorit neuveritelne produkty (treba http://www.datapower.com/products/xa35.html). Vzdy se zamyslete nad tim, kolik si pouzitim XML pridelate prace a kolik cinnosti si zjednodusite (a to nejen pro sebe, ale i pro ty co budou s programem datove komunikovat).

Jinak jsou i alternativy, treba YAML, http://www.yaml.org/

Myslím, že redukovat diskusi o XML na to, zda je dobré v něm psát konfiguráky, je až komická trivializace. Uvedu příklad, kdy jsem XML ve spojení s XSLT opravdu ocenil. Potřeboval jsem v C napsat API, které by pracovalo (tj. parsovalo nebo generovalo) s několika desítkami různých a navzájem dost nepodobných hierarchicky organizovaných datových zpráv (jež nebyly ve formátu XML a byly pevně stanoveny jinou externí aplikací - jeden komunikační systém v EU), umělo je ukládat/číst do/z SQL databáze a předávat programům dalších aplikací ve 4GL Informix. Psát kód ručně znamenalo zohlednit všechny datové struktury zpráv v C, v *.h include souborech, ve 4GL Informix a v SQL schematu databáze a při jejich změně opravovat kód na x místech. Vyřešil jsem to tak, že jsem vlastnosti všech datových zpráv popsal v jednom XML souboru a příslušné knihovny v C, , *.h soubory, kód ve 4GL Informix a SQL schemata generoval pomocí transformačních style-sheetů XSLT s použitím programu XALAN. Po počátečním boji s XSLT se postup ukázal jako nesmírně efektivní - datové zprávy byly popsány jediným XML souborem o asi 1400 řádcích a příslušné style-sheety měly každý max. asi 300 řádek - z toho většina je template kód v C, 4GL, resp. SQL. Pomocí tohoto aparátu mohu kdykoliv za pár vteřin vygenerovat několik desítek tisíc řádek v C, 4GL a SQL s jistotou, že vše, i při změně či přidání další datové zprávy (tj. změně pouze v definičním XML souboru), pasuje dohromady. Od té doby pokládám XML a nástroje s ním spojené za skutečně mocný prostředek.

To, co prezentujete ako Vase riesenie ma jeden vazny problem - nie je to systemove riesenie - je to bohapusty hack. Totiz, ked zmiesate funkcnost s datami (aspon tak som to pochopil) tak vam to bude fungovat pre male programy v pohodicke, ale ked vam projekt trochu narastie, tak to moze vyvolat viac problemov, nez osohu!!!
Mozete pokojne pouzivat sposob spustenia konfiguraku, ale nechcite, aby to niekto standardizoval, to je nonsens...