Názory k článku Akta X: EXI čili binární XML

jak se takovy binarni format da pouzit se systemy jako CVS nebo SUBVERSION. Ony totiz existuji programy u nichz je zadouci skladovat verze dokumentu (z hlavy me napada treba ulozeni elektronickeho schematu nejakeho zarizeni a jeho pozdejsi revize). Pouziti binarniho formatu by znamenalo upravu systemu pro spravu verzi. nebo se mylim?

Mylite se, CVS a SVN v pohode skladuji a porovnavaji binarni formaty ;-)

Kompilátory jsou špatné, protože binárky se špatně skladují v CVS a Subversion, nejde na ně diff...


Pokud někdo chce skladovat XML dokumenty v nějakém verzovacím systému, asi si nevybere binární serializaci a jestli ano, je to jeho problém.

Tak super, viditelne se ve W3C nepoucili z WBXML (Wireless Binary XML), coz je uplne otresny propadak, ale jeste navrch vymysleji EXI. Ja bych je kopal do zadku - nejlepsi binarni representace XML je gzip a hotovo. Implementace je tady 30 let, funguje to, je to ucine a hlavne se s tim nikdo nemusi delat znova. At si nekdo jen tak pro legraci zkusi naimplementovat prave WBXML (a neopisujte z libwbxml :-) a uvidi, jaka je to kravina.

1. wbxml resi neco jineho nez gzip dokumentu
2. wbxml jsme implementovali, libwbxml neopisovali a jako kravina nam to neprislo...

"Dokument XML je modelován jako proud událostí, které jsou v daném kontextu reprezentovány různě dlouhými kódy ... Dále může být použita dodatečná komprese na principu náhrady často opakujících se vzorů"

--- na tohle přece mohli použít gzip. Proč kvůli tomu vymýšlet nový formát?

W3M totiž musí nějakou práci alespoň předstírat, aby se mezi sponzory nevyskytly pochybnosti o užitečnosti konsorcia.

Snahy W3C maji perfektni smysl, ono to totiz s tim gzipem (a ani jinymi "general-purpose" kompresory) a XML neni zase tak skvele. Pokud vas zajima jenom redukce objemu dat, tak mozna (ale i tak se da ukazat, ze muzete komprimovat mnohem lepe, kdyz vite, ze komprimujete XML). Jakmile ale s komprimovanymi XML daty chcete pracovat, musite je rozbalit (bud vsechno, nebo po castech). To jednak neco stoji a jednak vas to pripravuje o flexibilitu pri zpracovavani XML obsahu. Naproti tomu, kdyz mate rozumny binarni XML format, muzete parsovat binarni data rovnou, bez nutnosti dekomprese ("binarni SAX"). Nektere binarni XML formaty vam dokonce dovoli vyhodnocovat urcite typy dotazu (XPath atd.) primo v binarni domene. Hlavni vyhoda binarniho XML ale spociva v tom, ze tim, ze pracujete primo s binarnimi daty, nejen ze odlehcite uloznemu/prenosovemu mediu (je nutne prenaset/ukladat mene bitu), ale take ziskate moznost rychlejsiho zpracovani dat (parser musi precist a analyzovat mensi pocet bitu)

Ale binarni XML bude taky mozny gzipovat a bzip2ovat a neco mista tak jeste usetrit :)
Jestli kompromovane binarni XML bude vetsi ci mensi nez obycejne je uz jina otazka...

No to je otazka, jestli je to rychlejsi. Sice se musi v textovem formatu po sbernici prenaset vice dat, ale zase jednotky (procesory), ktere ta data zpracovavaji obvykle pracuji s celymi byty a prace po bitech je vyrazne pomalejsi.

Nic ve zlem, ale vy jste asi nikdy neprogramoval na embedded zarizenich, ze? Popr. tam, kde musite minimalizovat toky dat za soucasneho zachovani jednoducheho zpracovani. Tady ma binarni XML ohromny potencial, soucasne textove XML je pro tyto ucely nepouzitelne - ohromne mnozstvi dat, velke naroky na zpracovani (cemz komprese ala gzip rozhodne prilis nepomaha). Osobne se tesim, az tohle bude uvedeno do praxe, misto toho, aby clovek musel pro kazdy pripad vymyslet format a kontejner pro data, tak bude moci pouzit standardni binarni XML, s spoustu nastroju (a knihoven) pro praci s nim.

Jinak mas pravdu v tom, ze to neni k nicemu. General-purpose kompresory nejsou vhodne, pokud zkomprimovana data chceme rovnou nejak zpracovavat. To, ze se i pro tyto ucely hodi nejaky typ prefixoveho kodovani, neni objevovani kola (jak se tu snazi nekdo prosadit), ale proste pouziti znamych vlastnosti znameho algoritmu ve specifickem pripade.

Jiste, jsou aplikace, kde binarni XML nebude vhodne, napriklad tam, kde se da ocekavat, ze by si ho nekdy chtel precist a pozmenit nejaky clovek (treba konfiguracni soubory). Obecne je ale XML format pro vymenu dat mezi stroji a tem je obecne uplne jedno, jestli jsou data zachlivkovana do bytu nebo symboly maji promennou delku.

Ona je otázka, za jakým účelem se to binární XML vlastně dělá.

a) Pokud se dělá za účelem rychlého zpracování, tak je třeba zapomenout na nějaké Huffmanovy kódy a hledání opakujících-se řetězců, protože tyhle věci zpracovávání zpomalují, nezrychlují. Pak se taky udivuji, proč v článku píšou, že je to "stream" dat, asi by bylo rozumnější, aby to byl strom, aby se daly přeskakovat elementy, co člověk nechce. Další věc, co by zpracovávání mohlo zrychlit, by mohlo být třeba přidat ke každému řetězci 32-bitový hash, aby se nechtěné elementy a atributy daly přeskakovat rovnou jedním porovnáním, a nebylo třeba dělat pomalé porovnávání řetězců po bytech.

b) Pokud se dělá za účelem zmenšení velikosti dokumentu (z článku jsem získal dojem, že tohleto byl cíl autorů), pak mi přijde divné, že komise navrhuje něco, co v podstatě používá kompresní algoritmy ze 70 let. Kdyby vztali nějaký současný kompresní algoritmus a vyřešili v něm problémy, kvůli kterým to XML komprimuje neefektivně (např. použili odlišné slovníky a statistické tabulky pro elementy/atributy/data), tak mi přijde, že by tím mohli dosáhnout daleko lepších výsledků.

On i ten gzip (i když jeho princip je jednoduchý) se vyvíjel mnoho let, aby byl rychlý a efektivní, tak pochybuju, že pokud si někdo sedne a řekne "já teď udělám kompresi opakujících-se řetězců", tak výsledek bude lepší než gzip.

bleku prosimti - kresli raci komiksy o svejch poruchach ...

Protoze sou vymlety? Jiny vysvetleni me nenapada. Kdyby predtim nez se sesedli k zelenemu stolu zadali par klicovych slov do vyhledavace, mohli prijit na to, ze binarni ekvivalent XML uz nekdo vymyslel. RFC je na to uz z roku 2004:

http://en.wikipedia.org/wiki/Extensible_Binary_Meta_Language

Kravaťácký "vynálezci" od XML právě vynalezli kompresi a Huffmanovo kódování. Blahopřejeme hoši!
Můžete se zase napakovat na konzultacích k vládním "projektům" a "informačním systémům" a lítat na EXI konference.

:)) 1+

Nepříjdu si jako kravaťák, a XML používám všude... gzip na redukci objemu dat bohatě postačuje. Ve velkém informačním systému je to jediné možné čisté řešení (struktura dat je přesně definována, a změny v komponentech se nemusí řešit).

Me to XML prijde ze zadny problem neodstranuje. Namisto problemu "jaky vyznam ma binarni polozka na offsetu 13" tam je akorat 1:1 problem "jaky vyznam ma tag blabla". Takze problem struktury dat to neresi.

Zato to prinasi obrovskou nevyhodu, a to je zvyseni mnozstvi dat a zesloziteni parsovani. Co se driv veslo do bajtu potrebuje ted 1-3 bajty (dekadicky zapis), co driv do 2 bajtu potrebuje 1-5 atd. Co bylo na fixnim miste musi se hledat. Kde byl vyznam dany implicitne je ted dan explicitne tagem a to zabira spoustu mista navic.

Jenže je to přenesitelné kamkoliv, stačí se domluvit s cizí firmou: data od nás lezou ve tvaru xxxxxxxxxxx a hotovo (API). Žádné další starosti, nic. Tohle je k nezaplacení a k tomu je to hlavně určeno. Já si bez něj aplikace neumím představit (protože po staru to byla pěkná prasárna, i když rychlejší).

A v čem to co řeší? Podle mě to je k ničemu. Akorát další zbytečná věc do světa počítačů, na níž se někdo může napakovat.

Az na to, ze kdyz ti pridam do binarniho souboru byte do hlavicky, tak se ti vyznam polozky na offsetu 13 znacne zmeni. U XML bude mit tag "jmeno" vyznam stale stejny, bez ohledu na to, jestli je na pozici 1 nebo 10 (teda pokud nejsem dobytek, jako jeden z dodavatelu naseho IS, ktery s klidem zmeni XML format tak, ze je puvodni parsovani nepouzitelne).

Podle me jste neco nepochopil. Dulezite je, ze s XML muzete mit jeden format pro vsechny mozne konfiguraky. Nemusite psat 100 parseru pro ruzne formaty, nemusite stokrat objevovat kolo. Kdo zna v tomto ohledu zmatek v /etc/, vi, o cem pisu. Navic pokud nejste pako jako inzenyri v microsoftu, tak ty vase konfiguraky muzou byt velmi pekne samopopisne, coz treba o takove crontabu tvrdit nelze. :-)

Raději pochopím pár různých jednoduchých konfiguráků v /etc, než abych se učil XML. Soubory XML jsou člověkem mnohem hůře čitelné, než klasické konfiguráky. Takže jsou nakonec zpracovatelné stejně jen pomocí nějaké aplikace a nic se neřeší, spíš naopak - zbytečně komplikuje.
A napsat parser umí každý, kdo má základy výpočetní techniky. Kdo to neumí, ať jde raději prodávat fialky místo toho, aby vymýšlel kraviny.

Možná by to chtělo odhalit roušku tajemství zkratky XML: Extensible Markup Language. Přičemž to první slovo je strašně důležité a vlastně je důvodem, proč je XML tak ukecané. Do té doby žádná binární (a vlastně ani textová) data neumožňovala tak jednoduché rozšiřování při zachování zpětné kompatibility a míchání více různých formátů do sebe.

Pokud však chcete jednoduchá data, která se budou měnit s verzí aplikace a na zpětné kompatibilitě vám nezáleží, pak je použití XML zbytečné.

Budou nové formáty natolik kompatibilní s XML, aby existující aplicace používající libxml nevyžadovala výraznější zásah v případě její migrace na binární formát?

Pokud ano, rýsuje se možnost výrazného zrychlení aplikací, které tráví většinu svého času parsováním XML.

Precital som si vsetky prispevky a az na dva mam dojem ze tomu nikto nerozumie. Robil niekto z vas co tu pisete XML parser (a validator voci XSD vratane namespace)? Uvedomujete si ze binarne XML sluzi hlavne na to aby sa tento XML to Memory alebo XML to internal structure nemusel robit? A az ako dalsia vlastnost je ze je to mensie. O velkost tu primarne vobec nejde.
Cez kolko vrstiev obvykle prechadza XML od povedzme klienta az po databazu? Rozumiete niektorym principom Enterprise message bus?
Potom nam sem nieco mudre napiste. Iniciativa je fajn. Treba to dotiahnut do praktickych implementacii. V kazdom pripade to velmi zrychli komunikaciu.
Trochu som sa rozohnil ale ludia co trepu do veci ktorym nerozumeju ma hrozne vytacaju a este sa tvaria ze oni su prave ti mudry. Lebo ak si niekto mysli ze ludia co pobehuju okolo W3C nevedie o Huffmanovej transformacii tak mate velmi naivne predstavy o fungovani sveta hraniciace s navstevou psychologa.

Máte pravdu, mě zase rozčilujou přechytralí fanoušci XML. Takové lidi je správné popíchnout.
Doufám že jste ten praser (u XML tomu odmítám říkat parser) nepsal v projektu nebo v grantu placeném z mých daní. A když už jsme u těch parserů pro stromové datové struktury, znáte Lisp?

Parser sme pisali v kamennej dobe XML. Potom ked sme ho chceli rozsirit tak sme presli radsej na standard (Xerces), aj ked bol pomalsi. Debatu XML vs. Lisp radsej znovu neotvarajme. Po zamene ( na < a ) na > je to skoro to iste, ale to berte len ako zartovnu poznamku ;-).

Já jsem z daní poplaníků České Republiky prodrbal 100 000 (za dvě konference). Absurdní na tom je, že kdybych ty peníze neprodrbal, tak by mě z university vyhodili za neaktivitu.

Blekovi to odpouštím, je pro mě kultovní linuxový progiš a nerd par excellence. Ale kravatózní šepleď bych věšel na šibenici za ty jejich barevně sladěné kravaty.

Mozna jsem vas uplne nepochopil, ale proc do toho zatahujete Enterprise service bus? Staci treba podmnozina - webove sluzby, ne?

Pretoze raz naparsovat to musite vzdy takze je jedno kedy. Nepredpokladam ze klient bude nieco na WS posielat v binary XML. Ale prave ked to XML prevliekate po buse hore dolu a ciastocne parsujete a ohmatavate na roznych miestach tak vtedy sa ta vyhoda prejavi.

PALO! JA TI DRZIM PALCE! MYSLIM ZE BY SIS DNESKA MEL UDELAT RADOST A JIT SI KOUPIT NOVOU KRAVATU!

Dik za radu, bol som si dat vycistit obleky.

Zrychlení zpracování XML zní rozumně, ale otázka je, proč se tam teda píše o bitových polích a opakujících-se řetězcích? To mi přijde, že ani samotní navrhovatelé neměli jasno, proč to dělají.

Clanek se mi nelibi, je znacne zkresleny a vzdy rikam, ze neni nad original.

Binary XML je skvele, uz se nemohu dockat az bude vsude podporovano. Samozrejme dojde opet ke snizeni vykonu, ale procesory jsou levnejsi, nez rychlejsi pripojeni k internetu a bude velmi pekne, az napriklad takovy xmlHttpRequest() probehne o 50% rychleji diky prenosu zkomprimovanych dat.

Nadruhou stranu muze byt problem, az zacnou firmy pozmenovat ona binarni data tak, aby je vetsina lidi nemohla pouzit - na obsfukaci jsou takovi ti praseci programatori primo spicky. Obcas se nevyznaji ani ve svem vlastnim kodu, natoz my po nich. Ukazkovy priklad mohou byt jmena a hodnoty formularovych prvku na strankach T-mobile.

Mě osobně se třeba líbí EBML z Matrosky (které je velmi rychlé a přitom úsporné - proč se vlastně nedostalo do Use Cases?), tak pokud se W3C podaří během parsování zachovat výkon, ale přidat možnost neznat DTD, tak tomu budu tleskat. Jinak bych zůstal u EBML.

Hmm, teda nevim jak vy, ale ja mam prohlizec podporujici gzip a pokud to je povoleno na serveru, tak se veskere prenosy komprimuji.

Doporučil bych obyčejné 32-bitové číslo, zarovnané na hranici 4 bytů. (předpokládám, že XML komise ještě nedosahují takové výkonnosti, aby standartizovali DTD s víc jak 2^32 elementů :-)

Huffmanův kód není špatná věc, jen by člověk u každého algoritmu měl zvážit, zda v daném případě jsou výhody přinesené algoritmem větší než nevýhody. Vy si taky do poznámkového bloku nepíšete poznámky Huffmanovým kódem --- sice byste ušetřil nějaký papír a tuhu, ale ztratíte spoustu času, když to budete kódovat a pak po sobě luštit :)

myslim ze se zde jedna o nejaky druh konspirace pratele ... nechci byt prilis paranoidni ale to konsorcium je rizeno z jineho solarniho systemu!
zajimalo by me - kolik toho jeste hodla tento spolek podelat a jak moc toho xml snese aby ho vsichni opravdu nenavideli i kdyz pro nektere aplikace je proste vic nez vhodne
no - nezbyva nez verit!!!