Vlákno názorů k článku Proč XML není jen bublina od Karel Ludanek - XML důsledně a od začátku NEpoužívá Unicode ale...

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.