Vlákno názorů k článku Akta X: EXI čili binární XML od BLEK. - "Dokument XML je modelován jako proud událostí, které...

"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