Atributy v XML

[Filip Jirsák]

A ještě k tomuhle. On v tom srovnání vysvětluje, proč použil tu ukecanější variantu. Je to proto, že XML dovoluje právě víc zápisů a v dost případech je použita právě ta delší. Vždyť i tohle vlákno začalo tím, jestli použít tu delší nebo kratší verzi. Takže dává smysl se ptát, jaká je cena za tuhle flexibilitu (obzvlášť pokud zůstane nevyužitá).

Ehm... Kdyby to aspoň napsal někdo jiný...

Použil tu ukecanější variantu, takže tu flexibilitu, že může použít i delší zápis, využil.

[Reklama]

[SB]

Jenže to je šetření na špatném místě. Třeba transformační a dotazovací jazyky mne nic nestojí, jsou vedle původního standardu a když nechci, vůbec je používat nemusím. Jenže i když chci serializovat nebo deserializovat jednoduchou datovou strukturu, jakmile opustím školní příklady, zjistím, že bych strukturu serializovanou jedním způsobem potřeboval deserializovat jinde, kde se očekává mírně odlišný formát, nebo potřebuju někde jenom ručně ověřit, kolik tam je vlastně položek atd. A najednou se mi hodí, že ty transformační a dotazovací jazyky mám po ruce a můžu je hned použít.

Ona ostatně není náhoda, že i pro JSON dotazovací jazyky existují, a myslím, že je snaha vytvořit i nějaký transformační jazyk. Takže všechno, co je na XML údajně zbytečné, se k JSONu postupně doplňuje. Akorát je trochu smutné, že JSON je vlastně takové „XML znovu a hůře“.

Měl jsem za to, že se bavíme o přednostech a nedostatcích formátů, ne o nezávislých nástrojích k nim vytvořených (které si koneckonců můžete vyrobit i sám).

[pako]

Měl jsem za to, že se bavíme o přednostech a nedostatcích formátů, ne o nezávislých nástrojích k nim vytvořených (které si koneckonců můžete vyrobit i sám).

jenomže xslt, xpath, xquery nejsou “nezávislé nástroje” ale provázané standardy.

[Kit]

Měl jsem za to, že se bavíme o přednostech a nedostatcích formátů, ne o nezávislých nástrojích k nim vytvořených (které si koneckonců můžete vyrobit i sám).

Bavíme se o výhodách a nevýhodách atributů v XML. Tedy něčeho, co JSON nezná. Dovedu si představit, že by se dal k JSONu vytvořit nějaký omezený JPath nebo JQuery, ale JSLT? Ne, na to ten formát nemá.

[Filip Jirsák]

Měl jsem za to, že se bavíme o přednostech a nedostatcích formátů, ne o nezávislých nástrojích k nim vytvořených (které si koneckonců můžete vyrobit i sám).

Pokud se budeme bavit pouze o samotném formátu a budeme ignorovat infrastrukturu, která kolem formátu existuje, bude vždy nejlepší nějaký vlastní proprietární formát vytvořený přesně na míru danému případu. Napíšete si k němu superrychlý parser, vlastní serializer a vše, co budete potřebovat.

V praxi to tak ale asi dělat nebudete, protože by pro vás bylo příliš nákladné vytvářet si i jen minimální infrastrukturu kolem toho vašeho formátu. Takže reálně nemá smysl porovnávat jen samotný formát, ale formát s celou tou infrastrukturou okolo. Proto se také v prohlížečích rozšířil JSON, protože v nich má lepší podporu než XML – a zároveň je tohle shodou okolností jediný důvod, proč se vůbec JSON rozšířil.

[Reklama]

[SB]

Pokud by to mělo být korektní, tak by to vypadalo takhle:

Kód: [Vybrat]

<user><id>%d</id><name>%s</name></user>
vs.
{"user":[{"id":%d},{"name":"%s"}]}...

Ale takhle to nikdo používat nebude, JSON vícevýznamové položky nevede, k ničemu to nepotřebuje.

Ale jestli takhle XML ukládá seznamy, tak tím bych si netroufnul se camrat - 1. nejde bez průchodu celé podstruktury poznat, jde-li o seznam nebo ne, 2. jednotlivé seznamy se mohou prolínat, 3. každý prvek seznamu prodlužuje zápis opakováním tagů názvu seznamu. 4. Zdvojuje se význam tagu na název seznamu obsahujícího položku a zároveň název samostatné položky. To má k eleganci a přehlednosti dost daleko.

[Kit]

Pokud by to mělo být korektní, tak by to vypadalo takhle:

Kód: [Vybrat]

<user><id>%d</id><name>%s</name></user>
vs.
{"user":[{"id":%d},{"name":"%s"}]}...

Ale takhle to nikdo používat nebude, JSON vícevýznamové položky nevede, k ničemu to nepotřebuje.

Ale jestli takhle XML ukládá seznamy, tak tím bych si netroufnul se camrat - 1. nejde bez průchodu celé podstruktury poznat, jde-li o seznam nebo ne, 2. jednotlivé seznamy se mohou prolínat, 3. každý prvek seznamu prodlužuje zápis opakováním tagů názvu seznamu. 4. Zdvojuje se význam tagu na název seznamu obsahujícího položku a zároveň název samostatné položky. To má k eleganci a přehlednosti dost daleko.

JSON i XML používají jen seznamy a slovníky. Co je myšleno tím prolínáním? Značky názvů seznamů jsou nepovinné. Dávají se tam kvůli lepší čitelnosti člověkem.

Jako značkovací jazyk by se mi líbil i Lisp, protože je ještě stručnější než JSON, ale neujal se. Možná i proto, že nemá ukončovací značku.

[gll]

Jako značkovací jazyk by se mi líbil i Lisp, protože je ještě stručnější než JSON, ale neujal se.

V kterém Lispu? Co konkrétně je stručnější než v JSONu? AFAIK neexistuje zápis mapy kompatibilní napříč Lispy.

[Karel]

Když navrhuji vlastní formát XML, tak je přede mnou rozhodnutí, zda pro danou hodnotu použiji element či atribut.
...
Jak navrhujete vlastní formáty XML? Proč dáváte přednost první variantě nebo proč druhé?

Já preferuji atributy. Snáze se mi s tím pracuje. Elementy použiji jen když chci ukládat text, který může obsahovat whitespace. Obzvláště když se tam může objevit konec řádku, protože s tím ani CTYPE nepomůže. Pro tyhle situace je pro mne výhodnější tam dát element a vyhnout se případným zmatkům s normalizací.

http://www.xml.com/axml/target.html#AVNormalize

[Kit]

Jako značkovací jazyk by se mi líbil i Lisp, protože je ještě stručnější než JSON, ale neujal se.

V kterém Lispu? Co konkrétně je stručnější než v JSONu? AFAIK neexistuje zápis mapy kompatibilní napříč Lispy.

Měl jsem na mysli takový zápis, který by snad měl být kompatibilní ve všech Lispech a zároveň řeší problém atributů, které v něm nemusí být skalární:

Kód: [Vybrat]

(user :id 42 :name "Název")
vs.
<user id="42" name="Název"/>
vs.
{"user":{"id":42,"name":"Název"}}


[gll]

Jako značkovací jazyk by se mi líbil i Lisp, protože je ještě stručnější než JSON, ale neujal se.

V kterém Lispu? Co konkrétně je stručnější než v JSONu? AFAIK neexistuje zápis mapy kompatibilní napříč Lispy.

Měl jsem na mysli takový zápis, který by snad měl být kompatibilní ve všech Lispech a zároveň řeší problém atributů, které v něm nemusí být skalární:

Kód: [Vybrat]

(user :id 42 :name "Název")
vs.
<user id="42" name="Název"/>
vs.
{"user":{"id":42,"name":"Název"}}


to by asi šlo, ale když JSON doplním o konstruktory, dostanu něco podobného.

Kód: [Vybrat]

user("id",42,"name","Název")


[gll]

Jako značkovací jazyk by se mi líbil i Lisp, protože je ještě stručnější než JSON, ale neujal se.

V kterém Lispu? Co konkrétně je stručnější než v JSONu? AFAIK neexistuje zápis mapy kompatibilní napříč Lispy.

Měl jsem na mysli takový zápis, který by snad měl být kompatibilní ve všech Lispech a zároveň řeší problém atributů, které v něm nemusí být skalární:

Kód: [Vybrat]

(user :id 42 :name "Název")
vs.
<user id="42" name="Název"/>
vs.
{"user":{"id":42,"name":"Název"}}


to by asi šlo, ale když JSON doplním o konstruktory, dostanu něco podobného.

Kód: [Vybrat]

user("id",42,"name","Název")


nebo asi lepe

Kód: [Vybrat]

user({id:42,name:"Název"})

je to stejně dlouhé

[Kit]

Kód: [Vybrat]

user({id:42,name:"Název"})
je to stejně dlouhé

Už tady bylo jasně řečeno, ža nezáleží na délce, ale na tom, co s tím umíš

[gll]

Kód: [Vybrat]

user({id:42,name:"Název"})
je to stejně dlouhé

Už tady bylo jasně řečeno, ža nezáleží na délce, ale na tom, co s tím umíš

mohu to vyevalovat stejně jako ten Lisp. Nebo pro tu Lispovou notaci existují nějaké nástroje?

[Kit]

Kód: [Vybrat]

user({id:42,name:"Název"})
je to stejně dlouhé

Už tady bylo jasně řečeno, ža nezáleží na délce, ale na tom, co s tím umíš

mohu to vyevalovat stejně jako ten Lisp. Nebo pro tu Lispovou notaci existují nějaké nástroje?

Záleží na tom, jak to v tom Lispu načteš. Když data čteš přes (read), tak se parsují do datového stromu, ale nevyhodnocují. Můžeš s nimi naložit jak chceš, třeba i ten eval, který nechceš.

Zkratka REPL znamená Read Evaluate Print Loop, což je smyčka, která se spustí na konzoli při načtení Lispu. Používá se pro načtení aplikace. Při načítání dat ze souboru tuto smyčku nepoužiješ, jenom čteš. V aplikaci si pak uděláš vlastní validaci a vyhodnocení dle potřeby. Funkce car a cdr jsou významným spojencem programátora.