Proč se v Javě XML nahrazuje YML?

[JS]

Povodne urcenie XML nie su textove dokumenty!
Je to strojovo aj ludsky citatelny format. Bol urceny na to aby ho citali stroje aj ludia.

Nebudu se snazit ti to vyvracet; jen poukazu na to, ze XML vzniklo ze SGML a ma mixed elementy. Smyslem XML bylo skutecne ujednotit ruzny markup textovych dokumentu (aby stejny text mohl obsahovat ruzne znacky).

K tomu CBOR, dalsi super binarny format snaziaci sa nhradit JSON?
Super nech sa postavi do radu... uz mame
ASN.1
BSON
MessagePack
Protobuf
a asi 15 dalsich na kolene urobenych nestandardnych formatov

Ked sa budem nudit vymslim si vlastny.

ASN je neco trochu jineho, Protobuf taky trochu neco jineho, ale BSON a MessagePack jsou podobne jako CBOR.

Nicmene autori CBORu se aspon obtezovali napsat decentni RFC (a poucili se z nekterych predchozich chyb), a proto je to moje osobni preference.

Ale ty si klidne posilej data, ktera mohou zustat binarni, v JSONu, nebo si napis vlastni binarni format. Podle me je to blbost. (Ujasni si, co chces svym argumentem rict - ze existuje mnoho ruznych binarnich formatu, a proto budes data posilat jako text, prestoze to neni vhodne?)

[Reklama]

[Petr]

Jen tak pro zajímavost. Tohle je zápis konfigurace připojení k databázi v XML. Není mi jasné, co způsobilo, že tomu JSON či YAML konkurují. Vždyť je to skoro stejné jako YAML a kratší než JSON. Krásně čitelné a zpracovatelné na mnoho způsobů.

Kód: [Vybrat]

<database
    host='localhost'
    dbname='test'
    user='root'
    password='heslo'
/>

Jednoduší použití. Zkus si tohle parsovat v javascriptu. A další nevýhoda je, že je to uživatelsky nepřívětivé pro ruční editaci. Pro tento účel je lepší ini.

[oss]

Jen tak pro zajímavost. Tohle je zápis konfigurace připojení k databázi v XML. Není mi jasné, co způsobilo, že tomu JSON či YAML konkurují. Vždyť je to skoro stejné jako YAML a kratší než JSON. Krásně čitelné a zpracovatelné na mnoho způsobů.

Kód: [Vybrat]

<database
    host='localhost'
    dbname='test'
    user='root'
    password='heslo'
/>

Jednoduší použití. Zkus si tohle parsovat v javascriptu. A další nevýhoda je, že je to uživatelsky nepřívětivé pro ruční editaci. Pro tento účel je lepší ini.

To nie je nevyhoda XML, to je nevyhoda javascriptu.

[Petr]

Ano, jako binarni format je urceny pro vymenu dat mezi pocitaci, neni to format vhodny pro konfiguraci.

Ale opravdu nevim, proc by s tim vyssi jazyky mely mit problem. Kazdy snad pouzije knihovnu? (Pripadne si ji napise, ale jen maloktery jazyk ma pro zpracovani binarnich dat horsi podporu nez pro zpracovani textovych dat.)

Co nechapes na tom, [..]

Jak jsem si myslel, diskuse s tebou nevede nikam jinam nez k urazkam.

Zkus si to nekdy sam - zjistis ze parsovat binarni data je casto jednodussi nez parsovat data textova. Pokud mas specifikaci; pokud ji nemas, tak clovek mozna o drobek lepe naparsuje text, ale porad ti bude chybet semanticka znalost o tech datech, kterou beztak musis mit, pokud je chces v aplikaci pouzit. Textovy vs binarni format je jen syntakticky detail, ktery dnes temer vzdy resi knihovny. (A to ignoruji problemy mnoha textovych formatu jako treba obcasna ztrata presnosti - ktere obcas mohou byt dulezite. Kdyby sis otevrel CBOR specifikaci, tak zjistis, ze ma dobre definovano, jake formaty cisel a tak pouziva.)

Nemáš pravdu. Textový formát se používá snadněji, protože s níj můžeš pracovat v univerzálním textovém editoru a je srozumitelnější a intuitivnější.

[Petr]

Jen tak pro zajímavost. Tohle je zápis konfigurace připojení k databázi v XML. Není mi jasné, co způsobilo, že tomu JSON či YAML konkurují. Vždyť je to skoro stejné jako YAML a kratší než JSON. Krásně čitelné a zpracovatelné na mnoho způsobů.é

Kód: [Vybrat]

<database
    host='localhost'
    dbname='test'
    user='root'
    password='heslo'
/>

Jednoduší použití. Zkus si tohle parsovat v javascriptu. A další nevýhoda je, že je to uživatelsky nepřívětivé pro ruční editaci. Pro tento účel je lepší ini.

To nie je nevyhoda XML, to je nevyhoda javascriptu.

Chybná úvaha, a proto ti také není jasné, co to způsobilo.

[Reklama]

[oss]

Povodne urcenie XML nie su textove dokumenty!
Je to strojovo aj ludsky citatelny format. Bol urceny na to aby ho citali stroje aj ludia.

Nebudu se snazit ti to vyvracet; jen poukazu na to, ze XML vzniklo ze SGML a ma mixed elementy. Smyslem XML bylo skutecne ujednotit ruzny markup textovych dokumentu (aby stejny text mohl obsahovat ruzne znacky).

K tomu CBOR, dalsi super binarny format snaziaci sa nhradit JSON?
Super nech sa postavi do radu... uz mame
ASN.1
BSON
MessagePack
Protobuf
a asi 15 dalsich na kolene urobenych nestandardnych formatov

Ked sa budem nudit vymslim si vlastny.

ASN je neco trochu jineho, Protobuf taky trochu neco jineho, ale BSON a MessagePack jsou podobne jako CBOR.

Ano je, ale stale je to serilizacia. A ano ASN.1 je take ake je, ale to kvoli dobe svojho vzniku. Ale plne nahradzuje (B/J)SON.

Nicmene autori CBORu se aspon obtezovali napsat decentni RFC (a poucili se z nekterych predchozich chyb), a proto je to moje osobni preference.

S ktorych chyb sa konkretne poucili?

[Petr]

Pouzivat XML nebo JSON na vymenu dat mezi systemy je zverstvo. Spravne by se melo pouzivat neco jako PB nebo CBOR.

V tom souboru CBOR nikde nevidím sémantické značky. Místo takových non-human-readable formátů je jednodušší použít textový formát s kompresí při přenosu.

CBOR ma uzivatelsky definovatelne tagy. A pouzit textovy format neni jednodussi, naopak.

Je zvláštní, že jsem nikde nenašel ukázku takového souboru. Zřejmě se ten formát moc nepoužívá.

Moc se nepouziva, protoze lide jsou jako ovce. Misto, aby pri volbe technologie resili technickou stranku veci, tak resi, kolik lidi to pouziva.

Byt pragmaticky neznamena byt ovce. Technicka stranka neni jedine kriterium.

[JS]

Ano, jako binarni format je urceny pro vymenu dat mezi pocitaci, neni to format vhodny pro konfiguraci.

Ale opravdu nevim, proc by s tim vyssi jazyky mely mit problem. Kazdy snad pouzije knihovnu? (Pripadne si ji napise, ale jen maloktery jazyk ma pro zpracovani binarnich dat horsi podporu nez pro zpracovani textovych dat.)

Co nechapes na tom, [..]

Jak jsem si myslel, diskuse s tebou nevede nikam jinam nez k urazkam.

Zkus si to nekdy sam - zjistis ze parsovat binarni data je casto jednodussi nez parsovat data textova. Pokud mas specifikaci; pokud ji nemas, tak clovek mozna o drobek lepe naparsuje text, ale porad ti bude chybet semanticka znalost o tech datech, kterou beztak musis mit, pokud je chces v aplikaci pouzit. Textovy vs binarni format je jen syntakticky detail, ktery dnes temer vzdy resi knihovny. (A to ignoruji problemy mnoha textovych formatu jako treba obcasna ztrata presnosti - ktere obcas mohou byt dulezite. Kdyby sis otevrel CBOR specifikaci, tak zjistis, ze ma dobre definovano, jake formaty cisel a tak pouziva.)

Nemáš pravdu. Textový formát se používá snadněji, protože s níj můžeš pracovat v univerzálním textovém editoru a je srozumitelnější a intuitivnější.

Ugh, precti si prvni vetu toho, co citujes.. Nicmene, proc bych mel chtit v textovem editoru editovat data, ktera vyrobil jeden program pro jiny program?

[JS]

Nicmene autori CBORu se aspon obtezovali napsat decentni RFC (a poucili se z nekterych predchozich chyb), a proto je to moje osobni preference.

S ktorych chyb sa konkretne poucili?

Uz je to delsi doba, co jsem si to porovnaval, ale jsou to v podstate spis drobnosti. Msgpack treba zezacatku nerozlisoval text a binarni data, pozdeji to tam pridali.

Pokud mi neveris, nejlepsi bude precist si vsechny tri specifikace, aspon ramcove. Rozhodne udelas lip, pokud pro vymenu dat zvolis jeden z tech tri formatu nez JSON (muzes-li si vybrat).

[Stefan]

Já vám nevím, prošel jsem projekty za posledních 18 let a YAML nikde. JAVA jako taková ani neobsahuje nic čím by se YAML dal číst.
Nejhorší je smrt z vyděšení ...

Stefan

[Kit]

Jen tak pro zajímavost. Tohle je zápis konfigurace připojení k databázi v XML. Není mi jasné, co způsobilo, že tomu JSON či YAML konkurují. Vždyť je to skoro stejné jako YAML a kratší než JSON. Krásně čitelné a zpracovatelné na mnoho způsobů.

Kód: [Vybrat]

<database
    host='localhost'
    dbname='test'
    user='root'
    password='heslo'
/>

Jednoduší použití. Zkus si tohle parsovat v javascriptu. A další nevýhoda je, že je to uživatelsky nepřívětivé pro ruční editaci. Pro tento účel je lepší ini.

Pokud budou data určena pro Javascript, použiji JSON.

Pro ruční editaci XML nemusíš používat textový editor, ale použiješ XML editor.

[Kit]

Stejne je to i u toho XML vs YAML. YAML asi vetsinou je citelnejsi, ale fakt je, ze je to temer opacny extrem nez XML, obcas si clovek neni jisty, jak v nem neco spravne zmenit nebo zadat (na druhou stranu, kdo si z hlavy pamatuje, ktere znaky je nezbytne escapovat v XML a jakou sekvenci?). Pokud se nebavime o puvodnim urceni XML (textove dokumenty), tak je to spis otazka vkusu.

Ja bych dal prednost YAMLu, ale uz driv jsem zde poukazal, ze dost mozna neni nutne delat tuto volbu - muzeme mit citelnost YAMLu a overitelnost XML (ackoli ruku na srdce - kolik lidi skutecne konfiguraci v XML rucne validuje a nespoleha na to, ze to udela aplikace sama?), a cele je to jeste radove vice DRY, jak zde nekdo napsal svuj pozadavek.

Kdo si z hlavy pamatuje, jak se escapuje v YAMLu?

Escapování i validaci dělají XML editory.

[JS]

Kdo si z hlavy pamatuje, jak se escapuje v YAMLu?

Escapování i validaci dělají XML editory.

No, uz je to tak 8 let zpet, co jsem XML potreboval editovat, ale byla to s temi XML editory pomerne bida (zadny z tech free, co jsem zkousel, validaci neumel, jen well-formedness).

Jinak mi prijde, ze si to trochu protireci. Pokud je XML zamerne textovy format, aby se dal snadno editovat, pak by mel stacit textovy editor.

[Petr]

Ano, jako binarni format je urceny pro vymenu dat mezi pocitaci, neni to format vhodny pro konfiguraci.

Ale opravdu nevim, proc by s tim vyssi jazyky mely mit problem. Kazdy snad pouzije knihovnu? (Pripadne si ji napise, ale jen maloktery jazyk ma pro zpracovani binarnich dat horsi podporu nez pro zpracovani textovych dat.)

Co nechapes na tom, [..]

Jak jsem si myslel, diskuse s tebou nevede nikam jinam nez k urazkam.

Zkus si to nekdy sam - zjistis ze parsovat binarni data je casto jednodussi nez parsovat data textova. Pokud mas specifikaci; pokud ji nemas, tak clovek mozna o drobek lepe naparsuje text, ale porad ti bude chybet semanticka znalost o tech datech, kterou beztak musis mit, pokud je chces v aplikaci pouzit. Textovy vs binarni format je jen syntakticky detail, ktery dnes temer vzdy resi knihovny. (A to ignoruji problemy mnoha textovych formatu jako treba obcasna ztrata presnosti - ktere obcas mohou byt dulezite. Kdyby sis otevrel CBOR specifikaci, tak zjistis, ze ma dobre definovano, jake formaty cisel a tak pouziva.)

Nemáš pravdu. Textový formát se používá snadněji, protože s níj můžeš pracovat v univerzálním textovém editoru a je srozumitelnější a intuitivnější.

Ugh, precti si prvni vetu toho, co citujes.. Nicmene, proc bych mel chtit v textovem editoru editovat data, ktera vyrobil jeden program pro jiny program?

Protože se to někdy hodí, protože to jde a protože je to snadné a pohodlné.

[Petr]

Jen tak pro zajímavost. Tohle je zápis konfigurace připojení k databázi v XML. Není mi jasné, co způsobilo, že tomu JSON či YAML konkurují. Vždyť je to skoro stejné jako YAML a kratší než JSON. Krásně čitelné a zpracovatelné na mnoho způsobů.

Kód: [Vybrat]

<database
    host='localhost'
    dbname='test'
    user='root'
    password='heslo'
/>

Jednoduší použití. Zkus si tohle parsovat v javascriptu. A další nevýhoda je, že je to uživatelsky nepřívětivé pro ruční editaci. Pro tento účel je lepší ini.

Pokud budou data určena pro Javascript, použiji JSON.

Pro ruční editaci XML nemusíš používat textový editor, ale použiješ XML editor.

Nemám ho po ruce, textový editor je součástí základní výbavy každého os. Nemusí se ti to líbit, ale nemá smysl čůrat proti větru. Plain text je pro konfiguráky oepší volba, json pro výměnu dat na webu zrovna tak. Tohle není žádné nařízení shora, celé to vyplývá z lidské přirozenosti. XML se nepovedlo na sílu protlačit ani do html, kam se hodil velmi. Na spoustu věcí je zbytečně formální a komplexní.