Názory k článku
Akta X 0309

sice taky povazuju kodovanido xml za hnus - ale musim se zastat komprese html - v pripade, ze se distribuuje vetsi mnozstvi textovych dat - tak komprese snizi trafic tak na tretinu a to je co rict - treba pri 5 GiB kvote jsou moje stranky schopny obslouzit cca 30 tis. navstevniku s komprimaci je to uz 90 tisic a to je co rict.

Vase stranky v XHTML se velmi pravdepodobne uz prenaseji zkompresovane. Ke kompresi dochazi na urovni weboveho serveru, ktery prenasena data automaticky komprimuje pomoci gzipu (pokud to klient umoznuje). Dnes ma podporu pro gzip kompresi vetsina webovych serveru a browseru.

Ja si myslim, ze duvody pro standardizaci binarniho formatu jsou jednoznacne a prukazne. Prirovnani XML k HTML v tom smyslu, ze pri nacitani HTML je vlastni objem techto dat maly, je hodne nepresne. XML jako univerzalni format se pouziva k vymene dat o libovolnem objemu. Naopak HTML stranky jsou obvykle dost male, protoze neni rozumne pro cteni vytvaret obrovske soubory. Tedy problem s usetrenim kapacity prenosoveho media je urcite prirozeny.

Narocnost parsovani na procesorovy vykon je z me zkusenosti take dost vyznamna, opet - pokud se jedna o velke objemy dat.

Binarni format bohuzel kazi jednu z hezkych vlastnosti XML - citelnost jak pro cloveka tak pro pocitac. Mohlo by se rict "tak proc nepouzit jiny, vlastni, binarni format, ktery by netrpel nevyhodami XML vyse popsanymi?". Protoze XML je standardni a dostatecne univerzalni. Tyto vlastnosti predurcuji XML jako zaklad binarniho formatu. Nebude problem (ve stylu XSLT napr) udelat transformacni parsery z textoveho do binarniho XML a naopak. Uz se na to tesim.

Ano, přesně na tenhle problém jsem narazil - nepříliš složitý formát, ale spousta dat a nutná velká rychlost zpracování. Pak převod z textu do bináru pochopitelně zdržuje. Někdy tak, že výsledek je nepoužitelný.

Takže binární doplnění XML by se hodilo. Otázka ovšem je, proč v se tom případě nespokojit s ASN.1, které je 1) vyzkoušené 2) vychytané 3) dostatečně univerzální a 4) pro binární přenosy přímo dělané.

Občas mi připadá, že se z XML stalo marketingové zaklínadlo, které se cpe (= je cpáno) i tam, kam se moc nehodí, a kde už existují jiná obecná řešení.

Ok, XML je zkratka komercne uspesne. Ja se priznam, ze nevim, jak vypada ASN.1, a proto by me nemohlo napadnout ho ve sve aplikaci pouzit. Nedokazu porovnat moznosti/vyhody/nevyhody ASN.1 a XML, ale chapu, ze kdyz ze vsech stran slysim XML, XML, XML...tak potom spolecnosti typu IBM, Sun, Microsoft nebo Nokia take krici XML, XML, XML a radne ho vyuzivaji ve svych aplikacich. To je zrejme obchod. XML se prodava. A kdyz zacina textove XML delat problemy s prostorem/casem, tak je pochopitelne, a z dnesniho hlediska i spravne, chtit binarni standard, ktery by alespon castecne tomuto ulevil.

Proc se ale XML tak prosadilo? Je to jen cisty marketing, nebo opravdu nejaka fakticka vyhoda?

Diky dobremu marketingu ho pouziva kazdy, aby byl in, a tak se z toho stal standard :-). I kdyz asi ten standardizacni ummysl byl na jeho zacatku.

take me uz napadlo proc moderni CPU nemaji i jednotku na parsovani XML (sax). Stacilo by zakladni predzpracovani UTF8 streamu pres DMA, knihovny by si obstaraly zbytek. Take by se urcite uzivila ZIP/UNZIP jednotka.
U binarnich XML je zasadni problem ze pri chybe v parsovani se zase (jako u binarnich souboru) nebude vedet jestli je chyba na strane autora streamu, nebo parseru, vetsinou to bude muset rozhodnout "master-parser" primo z W3C. V soucasne dobe se staci podivat textovym editorem a je to hned jasny.

Protoze RISC

Souhlasim a proto navrhuji vyjmout tuto jednotku z CPU a pridat ji jako samostatnou dokoupitelnou PCI kartu na desku :o)
Kdyz je dnes hw resena komprimace/dekomprimace pro servery, byla by to zajimava hracka :o)

http://www.datapower.com/products/xa35.html

neni to sice karta,ale ...

A proc proboha mel mit procesor jednotku na zpracovani nejakeho konkretniho formatu ? To mi prijde dost mimo, jako chtit po procesoru, aby mel jednotku na prehravani oggu :). Hardwarove akcelaratory, to uz je neco jineho, o nejakych kartach jsem slysel, ale reknete mi, kolik zakaznkiku to skutecne potrebuje ? Na domaci pocitac to asi bude zbytecny luxus. Pokud mate manii vsechno cpat do hardwaru, tak rozumnejsi reseni by asi byla nejaka karta s hradlovym polem.

Pochyby o nutnosti komprese XML a srovnavani XML s XHTML a HTML je nepochopeni vyznamu a moznosti XML (bud mnou a nebo autorem clanku). Mam za to, ze XML ma slouzit (i) pro vymenu dat. Tedy nejen soubory XSL, XML Schema, SOAP, WSDL..., ale treba SVG nebo GML.

Ja pracuju v GIS oblasti (elektronicke mapy), kde prevod vektorovych dat do XML (to je to GML) vede treba k desetinasobnemu narustu velikosti dat. A jedna se o desitky megabajtu dat v GML za jednu vrstvu (kraje, okresy...). Z toho duvodu je nutnost komprese asi jasna.

Osobne se priklanim k reseni, ktere je pouzito napriklad v OpenOffice. Formaty dokumentu OO jsou zazipovane XML soubory, kterym je pak zmenena pripona. Zkuste zmenit priponu na ZIP a pak dostanete XML soubor. Takze takhle nejak bych si predstavoval reseni. Asi nejjednodusi, pruhledne a tak.

Stepan

Potíž je v tom, že je potřeba provádět komprimaci streamů, nikoliv jen celých dokumentů. Dokonce nejen on-fly komprimovat a dekomprimovat, ale i parsovat - a v tom je pravděpodobně kámen úrazu. Jak už tu někdo zmiňoval, bude třeba řešit situace, kdy stream nebude validní (resp. nezkomprimované XML nebude validní) - což asi nebude triviální věc.

Mě spíš zaujala autorova poznámka o tom, že binární XML umožní výrobcům SW přidávat vlastní funkčnost. Nemám pocit, že bych úplně rozuměl, co tím chtěl básník říct. Že výrobci SW chtějí opět nedodržovat standardy? Nebo jim snad současné XML neumožňuje dodávat do (svého) XML vlastní funkce? Nebo že jejich úžasné nové funkce může někdo snadno přečíst? Ale to přece půjde s binárním XML taky...

Taky jsem zvědav, co se z toho vyvrbí...

Ja to pochopil tak, ze marketingove oddeleni bude mit co dat do reklamich materialu: "Nove funkce, rozsireni XML modulu - za pouhych 999,95 $ si kupte nasi novou verzi s binarnim XML I/O nebo za 999,90$ zlevneny upgrade na tuto verzi :)" Proste aby zase bylo co prodavat... :/

ad nepochopeni vyznamu: XML jednoznacne vzniklo a bylo zamysleno jako jazyk pro web. Tim ze se dnes pouziva pro vse mozne i nemozne, narazi pochopitelne na sve limity. Zminene SVG a GML jsou aplikace, ktere jsou puvodnim zamerum znacne vzdalene; nemuze tedy byt divu, ze jim XML vyhovuje jen castecne. Snaha okrajovych oblasti (z hlediska designu XML, nic pejorativniho) o priohnuti XML svym smerem je pochopitelna, stejne jako odpor/neduvera priznivcu puvodnich zameru. Ma se XML rozsirovat, aby uspokojilo vsechny, az treba nakonec neuspokoji nikoho? Nebo ma delat jen to, co umi, a pro jine oblasti at se hledaji vhodnejsi formaty? To je obecnejsi rovina sporu o binarni XML.

Heh, a ja si vzdycky myslel, ze XML vzniklo jako "zjednoduseni" SGML. A to, pokud vim, nema nic moc spolecneho s Inetem. Spis si myslim, jestli Petr C. nezamenil XML za XHTML ci starsi HTML. To jsou, pokud vim, nareci jazyka XML urcena pro web.

Stepan

Proc by format vznikly zjednodusenim SGML automaticky nemel mit nic spolecneho s Inetem? Zpusob odvozeni snad vylucuje moznosti pouziti?

Ve starych draftech z roku 96 jsou k videni "XML design principles". Cislo 1 je: "XML shall be straightforwardly usable over the Internet". FYI, jen o kousek dal stoji "XML shall be compatible with SGML".

Prestoze to tak v dnesnim boomu nevypada, XML opravdu vzniklo kvuli webu, v dobe velke webove exploze a pod zastitou webove organizace (W3C).

Taky mi připadá, že XML vzniklo ne tak docela kvůli inetu. Prostě se počítalo s tím, že má být přes inet snadno přenositelný a použitelný v multiplatformovém prostředí. Čehož se snadno dosáhne přes texťák, kde není problém s endiány, doplňky atd.
Je to technologie na málo strukturované dokumenty, jak je strukturovat aspoň nějak. Typicky na dodání sémantiky do textů. Ovšem, proč se musí do XML přepisovat databázová tabulka, která je už z principu strukturovaná dobře, netuším.

Kde se musí předávat numerická data (ale nejen numerická), tam se dá s výhodou použít ASN.1. Převod do/z BER je (musí být) rychlejší než přes texťák, o zvětšení dat nemluvě. A když se použije PER s jeho téměř socialistickým principem "ani bitík nazmar", tak kódování/dekódování nemusí být o moc pomalejší (přece jenom

Chci napsat jen takovou poznamku. Z vety
"XML shall be straightforwardly usable over the Internet" mi vyplyva, ze XML je/bude/mely-by-byt urceno pro Internet (s cimz souhlasim). Kde je ta zminka o Webu (coz je pouze jedna z aplikaci/protokolu) Internetu?
Prave ze XML je urceno pro strukturovana data typu SVG, ktere maji stromovou strukturu (viz znacka <g> apod.).

No, mně z té věty vyplývá, že XML má být použitelný přes internet, ne že by byl primárně určen pro internet. Jeho určení je mnohem obecnější, ale dá se taky užívat via internet, tedy v heterogenním prostředí.

Neopiram svuj nazor o zadnou jednu konkretni vetu nebo dokument. Dulezity je celkovy kontext vzniku XML, pozadavky, prvni drafty, korespondence mezi autory, tehdejsi situace Internetu, apod. To vse je dodnes dostupne na webu. Nemuzu ani nechci vyvracet kazdy jednotlivy nazor ci pocit. Konec koncu, kazdy ma pravo na ten svuj.

Binarni zapis XML by byl jednoznacne prinos - vyhoda textovosti (citelnost pro cloveka) s sebou nese totiz zbytecne zpomaleni pri parsovani pocitacem. Holt pocitace jsou digitalni/binarni a tak by mely dostavat takove formaty. A pro cloveka: neni prece problem udelat k tomu modul, ktery kdyz otevrete binarni XML v "textovem" editoru, tak vam to zobrazi textove.

Samozrejme ze se binarni zapis nedela kvuli souborum o desitkach kB (web stranky), ale hlavne kvuli tem, ktere maji nejmene tisickrat vetsi velikost...

Jo, a to zipovani, ktere pouziva openoffice neni podle mne idealni reseni pro pripravovane binarni XML - ono to sice usetri vic mista, ale zhorsi to rychlost nacitani a znemozni to cist dokumenty odprostredka...

Me hlavne desi, ze k tomu zase Microsoft pristoupi se svym broukopytlikovskym sarmem a zase tu budou dve xml, v textove podobe vydite hned, kdo je blbec a nedodrzuje standardy, v binarce to muzete hledat hodiny.

Prominte, ale Vy znate nejaky nastroj, ktery umi cist XML data odprostredka?

Ačkoliv mi při pomyšlení na binární verzi XML hrůzou vstávají vlasy na hlavě, musím přiznat, že by své opodstatnění mohla mít. Představte si, že potřebujete malý fragment dat z velikého souboru. Dnes musíte parsovat a validovat celý dokument, zatímco u rozumně navržené binární podoby byste mohli přistoupit přímo k požadované části XML dokumentu. Nebo by bylo možné zpracovávat i velké dokumenty, které se by v operační paměti zabíraly velké místo (např. při XSLT transformacích).

Podmínkou je samozřejmě zachování modelu XML dokumentu a jednoznačné a oboustranné mapovaní mezi textovou a binární podobou.

Stoprocentní souhlas, skoro bych řekl, že jste mi to opsal z hlavy ;-))

Ale kvůli tomu nemusíte vyvíjet a standardizovat binární formát. Stačí si dokumenty XML uložit do nějaké nativní XML databáze, a ta se už postará o to, aby vám rychle vrátila data třeba od půlky dokumentu.

Standardizace binárního formátu vám v tomhle nepomůže, spíš uškodí. Buď ten formát bude navržený geniálně pro rychlou navigaci a bude nejspíš patentovaný, nebo bude hloupý a pro nějaké rychlé vyhledávání nepoužitelný a nikdo ho nebude používat.

Jeden uz existuje - Wap (resp. Wireless) Binary XML, http://www.w3.org/TR/wbxml/ ale neni az tak obecny.

Uspora v sirce pasma se hodi i dnes a myslim, ze to jeste nejakou dobu platit bude (napr. na GPRS a jeho pripadnych nastupcich)

Zrychlene parsovani urcite prijde vhod ve webovych sluzbach (SOAP).

Zpracovani velkych objemu XML dat je, rekl bych, jina otazka. Jestli je XML pouzito jen jako vymenny format mezi ruznymi systemy, pak pripadne staci komprese, import/export dat je jedorazova zalezitost. Jestli se s temi daty opravdu pracuje, klicove z celeho XML jsou standardy pro praci s takto strukturovanymi daty (API DOM, XPath, ...),
ktera by mela byt ulozena v nejake XML databazi. Implementatori takove DB si uz nejaky rozumny (nejspis binarni :) format vymysli.

(Paralela z relacnich databazi: kdyz pracuju s velkym objemem relacnich dat, taky nepracuju s SQL dumpem, ktery bych parsoval a nacital do pameti, ale pracuju s DB serverem, ktery mi k nim poskytuje pristup. Ze by nekdo chtel standardizovat binarni format dat relacnich DB serveru jsem si jeste nevsiml :)

úplně žluťoučký kůň úpěl ďábelské ódy

Příliš žluťoučký kůň úpěl ďábelské ódy!

Ha!
opět slyším koně úpět ďábelské kódy a napadlo mne, že vlastně nevím, kdo tuhle tuhle větu pro otestování češtiny použil první?

Pamatuju si ji z dob počátků Internetu, ale docela by mne zajímalo, kdo ji tak šikovně vymyslel...

Ruku do ohně bych za to nedal, ale myslím, že vynálezcem této geniální testovací větičky je pan Satrapa.

Vojta

Příliš žluťoučký kůň úpěl ďábelské ódy!

velke spolecnosti maji velke projekty, ktere jsou nasazeny kdo vi kde a kdo vi jak dlouho.

nemaji zajem do nich ani jejich behu jakkoliv zasahovat.

naopak, protoze je uz maji hotove, rady by je jeste nekolikrat prodali a tomu prospeje dalsi argument: standardizovany format vymeny/ukladani dat s durazem na slovo "standardizovany" a tichym "dodatecne nove"

Protože pro efektivní výměnu binárních dat s jasně definovanou syntaxí zde skutečně existuje ASN.1 a BER/DER/CER/PER... Mimochodem, těm trvalo 20 let, než se vychytaly - zase ten výsledek posledních verzí ASN.1 je také docela sporný.

Nicméně v praxi asi pokus o binární reprezentaci vznikne, prostě proto, že v XML je dnes již přeci jen docela hodně dat. Vývoj IT mi přijde jako stále oblékání nových kabátů na již vynalezené věci, ale tak to prostě chodí. Jak to bude úspěšné, se uvidí. Možná jo, možná ne.

XML má svůj dobrý technický důvod existence, hlavní hráči na trhu se na jeho tvorbě a podpoře dohodli dávno před tím, než to začali marketovat.

Ukládat boolean do 3 bajtu, hmm hmm.