Vlákno názorů k článku Akta X: Porovnání současných binárních formátů XML od pexxi - A nestacilo by napr. LZW skomprimovane XML, namiesto...
-
CyberBob66 (neregistrovaný)"to je asi tak jako s celym xml dohromady"
Z XML by se neměla dělat modla, ale přesto s si dovolím nesouhlasit.
Například kurzové lístky ČNB jsou stažitelné v textových CSV souborech, bylo by nesmyslné na takový úkol používat XML. Jsou to plochá data, která si v CSV můžu parsnout třeba na 15 let staré 386 v dosu (nebo v linuxu :)
Ale pak je mnoho případů, kde je XML velkým pomocníkem - např. konfigurační soubory, málokdy máte strukturu tak jednoduchou, aby to šlo napsat ve dvojicích klíč-hodnota. Např. v INI souborech jsou skupiny. V jiných konfiguračních souborech je jiná struktura, někdy i do více úrovní. atd. každý si to dělá po svém, obvykle musíte zkoumát, jako strukturu má ten který konfigurák. Navíc, když to bude v XML, můžu si snadno ověřit, jestli je nastavení po formální stránce v pořádku - stačí zvalidovat dokument oproti DTD nebo schématu. A vím, že program nezhavaruje nebo neskončí chybou proto, že jsem v konfiguráku zapomněl středník nebo lomítko.
V XML taky můžu napsat objednávku, která obsahuje např. položky zadavatele (adresa) a pak neomezené množství položek k objednání. Jak to napíšete v textovém souboru? Jako položka1="..." položka2="..." atd.? XML je na strukturovaná data jako dělaná.
"proc pouzit jednoduche reseni kdyz to jde sloziteji" - ano, je zbytečné používat XML na nestrukturovaná jednoduchá data, ale taky je nesmysl XML apriori zavrhovat. -
su - \mathfrak{M}ĦĒNJMARCHON (neregistrovaný)Tak sa mi zda, ze takto dokonvergujeme k ASN.1 ;-)
Rozdiel medzi ASN.1 a klasickym XML je v tom, ze ASN.1 ma oddelenu definiciu struktury od dat. Vyhoda takeho pristupu je, ze je napr. mozne napisat jednoduchy codec na predom definovanu strukturu, co moze byt vhodne pre embedded systemy - nizsia narocnost na CPU/pamat. Program potom nemusi napr. dekodovat cislo z textovej reprezentacie do "beznej binarnej". Viz tiez preddefinovane struktury, OID repository (http://oid.elibel.tm.fr/).
Nakoniec existuje one-to-one correspondence (bijekcia) medzi XML a ASN.1 (http://asn1.elibel.tm.fr/en/xml/). -
su - \mathfrak{M}ĦĒNJMARCHON (neregistrovaný)Jj, myslel som tym toto:
v XML:
<category name="Debugger" replace="debugging"/>
v ASN.1:
definicia:
category ::= SEQUENCE
{
name VisibleString,
replace VisibleString
}
Zakodovany binarna struktura nebude obsahovat samotne retazce "name" a "replace", len ich hodnoty "Debugger" a "debugging". -
Makovec (neregistrovaný)Opravdu je každé binární xml zakodované tak, že se s ním nedá okamžitě pracovat (provádět na něm transformace a dotazy)? Ostatně co to znamená "rozbalím" -> s XML se stejně obvykle nepracuje jako s textem (který dostanete po "rozbalení"), ale naparsuje se do nějaké "binární" struktury...
-
CyberBob66 (neregistrovaný)
Tuším vaší motivaci, ale mám asi jiný názor na to, k čemu používat XML, proto si asi nerozumíme.
Co se stane, když přenesete naparsované binární XML po síti, nehrozí že se poškodí (nebo ho někdo záměrně poškodí) a vy si toho nevšimnete, protože ho nebudete znovu validovat? Nebo budete počítat kontrolní součty? To je ale taky další zátěž procesoru, možná menší než vlastní parsování, ale efekt se tím značně snižuje.
XML vidím jako prostředek pro přenosy malých objemů složitě strukturovaných dat. Zajímavé jsou také XML databáze (ty bych ale nejraději viděl jako transparentní mapování relačních tabulek na XML struktury).
Jestli chce ale někdo pomocí XML nahrazovat databáze nebo přenášet gigabajty, tak ať se klidně pachtí s nějakým binárním xml, je to jeho problém. Já to ale považuji za ztrátu času.
-
Makovec (neregistrovaný)Ano, xml je velmi vhodné na to co píšete. Ale to neznamená, že neexistují situace, kdy ho lze použít i jinak, a má to své opodstatnění.
Např. potřebujete přenášet relativně* velké objemy strukturovaných dat do zařízení, která mají velkou paměť (storage) ale nízký výkon procesoru, která jsou připojená jenom jednou za čas, pomalu, draze atp. a vy tam potřebujete ta data celá, protože v době kdy můžete** přenášet ještě nemůžete vědět, co z nich budete potřebovat (např. jízdní řády do PDA nebo mobilu) a vyžadovat po je po kouskách nemusí být v okamžiku kdy je právě potřebujete možné. Jistě by se takových příkladů našlo víc.
Pak by bylo fajn mít možnost, stejně jako u klasického "textového" XML, použití nějakého standardu, jednotného formátu a dotazovacího jazyka a API pro manipulaci s těmito daty. Binární xml se nabízí jako úprava osvědčeného formátu, a používá třeba v těch mobilech (wbxml).
*) vzhledem k propustnosti připojení, výkonu klientského zařízení etc.
**) nebo je výhodné je přenášet vzhledem k časové závislosti propustnosti připojení, cenové tarifikaci etc. -
CyberBob66 (neregistrovaný)1) Ano, jsou případy, kdy by se binární xml hodilo, ale: náklady (čas, peníze) na jeho vývoj považuji za vyšší než jeho přínosy, proto se na jeho vývoji podílet nebudu :-)
2) Pokud budu mít větší množství dat, budu je ukládat do DB. Dnes pravděpodobně do relační, v budoucnu třeba do nativní XML databáze (ale to až budou na takové výkonnostní úrovni jako dnešní relační a stejně vyspělé)
P.S. nechci tady flamovat :-) jen si myslím, že jsou jiné věci, kterými má cenu se zaobírat, než zrovna binárním kódováním XML. -
CyberBob66 (neregistrovaný)Je možné použít cokoli, gzip, zip, bz2... možností je mnoho a nejsou mezi nimi takové rozdíly*
Samozřejmě se vnucuje myšlenka, že pak budu muset rozbalovat všechno, když chci třeba jen část. Tato obava je ale lichá. Pokud ty data nepotřebuju, nebudu je ani přenášet.** Z čehož plyne, že všechna data, která jsem přijal/odeslal potřebuji. Tudíž nevadí, že je rozbalím najednou.
Příklad z praxe v javě: použiji GZIPovaný vstupní/vystupní proud a není co řešit ;-)
*)rozdíl objemu mezi komprimovaným a nekomprimovaným XML je obrovský, ale rozdíl mezi komprimovaným tak a jinak je méně významný.
**) Pokud se bavíme o kompresi, pak nám tedy záleží na objemu dat, která přenášíme. Proto nebudeme přenášet data, která nepotřebujeme. -
CyberBob66 (neregistrovaný)1. Záleží vždy na nejužším místě a tím jsou dnes často přenosy.
2. přesně tak, navrhnu systém tak, aby se v něm nepřenášela zbytečná data. Jestli jsou nějaká data zbytečná, nebudu je posílat a asi ani ukládat. Budou-li nějaká data "možná" potřeba, pošlu je, až budou skutečně potřeba. Nebo je pošlu předem, aby se nakešovala, ale pak počítám i se všemi nevýhodami kešování. -
Máme-li XML soubor třeba XHTML o velikosti 10MB, komprimoval bych to po částech, aby se nemusel složitě a dlouze rozbalovat celý soubor... určitě zabalit <head> samotnou a pak teda asi tělo rozkouskovat třeba na divy, nebo na něco menšího, než celé <body>.
Komprimace by měla být hlavně rychlá a na paměť nenáročná...určitě bych to nekomprimoval algoritmem, který půjde tvrdě po nejnižší velikosti.
Ale pánové určitě najdou nejlepší řešení :-)
Co se týká csv, tak tam bych se určitě nebál přejít na xml...nemusí být nijak složité...podle mého bude rozhodně přehlednější a o to jde také, ne? -
Palo (neregistrovaný)Jezis. Vy ste ako male deti. Ved to binarne XML sa nerobi iba preto aby to bolo binarne za kazdu cenu. Problem je v serializacii a deserializacii dat. Ako uz raz rozparsovane XML preniest nekam inam tak aby sa nemuselo znovu textovo parsovat, a nebodaj validovat.
Ta kompresia by vam pridala iba dalsi overhead. ASN je good ale potlaca samotnu existenciu XML pretoze ho zbavuje pridanej informacie v podobe nazvov atributov, zostanu iba ciste data.
Ked vytvarate naozaj velke systemy zistite ze XML je skvela vec. Ked sa zamyslite nad roznymi verziami toho iste interface ktory koli kompatibilite musite vo svojich systemoch ponechat zive, strukturalnej sile ktore XML poskytuje. Ako priklad by som zobral prispevok niekoho na zaciatku diskusie. Preco nie je lepsie ulozit kurzovy listok v XML? Co ked pribudne nejaka mena? Co ked ubudne nejaka mena? Kde to v CSV bude? V XML to bude skoro vzdy OK akurat odobrana mena bude null alebo 0. -
CyberBob66 (neregistrovaný)Příklad s kurzy jsem vybral zcela záměrně, jako příklad toho jak je zbytečné používal (jinak skvělé) XML na jednoduché věci.
Odkaz dole na téhle stránce: http://www.cnb.cz/cz/financni_trhy/devizovy_trh/kurzy_devizoveho_trhu/denni_kurz.jsp
Soubor vypadá takhle:
22.08.2006 #162
země|měna|množství|kód|kurz
Austrálie|dolar|1|AUD|16,761
Bulharsko|lev|1|BGN|14,400
Čína|renminbi|1|CNY|2,759
Dánsko|koruna|1|DKK|3,775
EMU|euro|1|EUR|28,165
Estonsko|koruna|1|EEK|1,800
Filipíny|peso|100|PHP|42,837
první dva řádky budu ignorovat, další rozdělím podle svislítka, vím, co který sloupeček znamená, a jednoduše je načtu do nějaké struktury (podle toho, v čem programuju).
XML by přineslo výhodu jen ve validaci, kdyby se změnila struktura dat zjistil bych to, tak, že xml bude nevalidní. V CSV to nezjistím, resp. zjistím až dojde k chybě. Ovšem kurzový lístek je věc, která se nemění, i za 20 let může mít stejnou strukturu. Maximálně některé měny přibydou, jiné ubydou, ale struktura bude stejná. Proto pro tyhle potřeby plně vyhovuje CSV.
XML by naopak přineslo i nevýhody:
-objem dat by vzrostl odhadem na dvojnásobek
-lístek by se musel "složitě" parsovat místo toho, aby se jen rozdělil text podle svislítek
--> větší záhul pro přenosové linky a procesory na obou stranách. Asi vám to přijde legrační a zanedbatelné. Ale je zbytečné dělat věci složitě, když to jde jednoduše (jak už poznamenal někdo výše :) -
su - \mathfrak{M}ĦĒNJMARCHON (neregistrovaný)"ASN je good ale potlaca samotnu existenciu XML pretoze ho zbavuje pridanej informacie v podobe nazvov atributov, zostanu iba ciste data."
Nie nutne. Co trebars:
attribute ::= SEQUENCE
{
name VisibleString
value VisibleString
}
Pokial sa dobre pamatam, povoluje ASN.1 aj optional atributy, takze nie je problem pridavat/vynechavat. Nakoniec, samotnu definiciu je mozne zakodovat v ASN.1 ;-)
BTW, na serializaciu, inak nazyvanu aj marshalling, existuje hrozne vela nastrojov/jazykov, napr. IDL (interface description language). -
CyberBob66 (neregistrovaný)
1) Mám knihu jejíž zdroják v TeXu má asi 500 kB a má to přes 350 stran. Jaké XHTML bude mít 10MB? Vzhledem k tomu, že je to xhtml tak je možné, že to budu stahovat po síti. Proč bych měl stahovat 10 MB, když mne zajímá třeba jen hlavička, nebo první stránka??? Jak jsem tu už někde psal: nebudu posílat/přijímat data, která nepotřebuju.
Možné je, že jsi do těch 10 MB chtěl nacpat i obrázky, ale to mi přijde jako extra zhovadilost. Jednak ne každý ty obrázky chce a jednak není dobré nahrazovat souborový systém nějakým formátem a cpát to všechno do jendoho souboru*
2) K CSV - jestli to funguje a funguje to dobře a navíc je to přehledné, tak proč do toho šťourat?
22.08.2006 #162
země|měna|množství|kód|kurz
Austrálie|dolar|1|AUD|16,761
Bulharsko|lev|1|BGN|14,400
Čína|renmin bi|1|CNY|2,759
Dánsko|koruna|1|DKK|3,775
Myslíš, že tohle bude v XML přehlednější? Akorát tam přibydou desítky menšítek a většítek a textu bude asi 2x tolik. XML je skvělá věc, ale je zbytečné ho používat na takto jednoduchá data.
*) Často mne např. štve, že musím čekat na rozbalení celého tar.gz souboru, přestože se chci jen podívat, jaké soubory obsahuje. U zipu to vidím hned, ale u 10 MB tar.gz to trvá citelné déle.
