Atributy v XML

[Kit]

Když navrhuji vlastní formát XML, tak je přede mnou rozhodnutí, zda pro danou hodnotu použiji element či atribut. Z mého pohledu je to podobné rozhodování, jako v OOP umístění skalárních dat do samostatného objektu nebo do atributu. Oba přístupy mají něco do sebe (pro i proti) a výsledkem by měl být nějaký kompromis.

Narazil jsem však na jedno schéma, které se drží jednoho z extrémů, tedy všechno v elementech, ale nic v atributech:

Kód: [Vybrat]

<pluginRepository>
    <id>snapshot-repo1.php-maven.org</id>
    <name>PHP-Maven 2 Snapshot Repository</name>
    <url>http://repos.php-maven.org/snapshots</url>
    <releases>
        <enabled>false</enabled>
    </releases>
    <snapshots>
        <enabled>true</enabled>
    </snapshots>
</pluginRepository>

Většina z vás jistě pozná úryvek z konfiguráku Mavenu.

Trochu jsem si s tím návrhem pohrál a udělal jsem z toho opačný extrém, tedy vše v atributech:

Kód: [Vybrat]

<pluginRepository
    id="snapshot-repo1.php-maven.org"
    name="PHP-Maven 2 Snapshot Repository"
    url="http://repos.php-maven.org/snapshots"
    releases="disabled"
    snapshots="enabled"
    />

Informační obsah stejný, velikost a přehlednost rozdílná.

Pomiňme, že v Mavenu to jistě nikdo měnit nebude, ale takových dat a konfiguráků mi rukama prošlo už hodně. Některé byly ještě ukecanější a méně přehledné než první ukázka, např. klíč a hodnota v samostatných elementech uzavřené do dalšího nesémantického elementu. Jak navrhujete vlastní formáty XML? Proč dáváte přednost první variantě nebo proč druhé?

[Reklama]

[Franta <xkucf03/>]

Používám jak elementy, tak atributy. Atributy jsou stručnější a přehlednější, ale můžeš u nich v budoucnu narazit. Základní pravidlo je: bude tu vždy ta hodnota jen jednou a bude atomická? Pokud je odpověď jednoznačné ano, tak není problém z toho udělat atribut. Pokud nevím nebo plánuji rozšíření (podpora více prvků nebo nějaké vnitřní členění, doplnění atributu k atributu), tak spíš element.

Ono není až taková tragédie udělat verzi formátu 2.0 a v ní přejít z atributů na elementy, ale to bych si nechával spíš na větší změny a při běžném vývoji se snažil jít spíš evoluční cestou (např. přibude nepovinný atribut).

Nacpat všechno do atributů může mít v některých případech racionální vysvětlení nebo nějakou myšlenku. Někteří lidé totiž kritizují XML za to, že je moc složité a umožňuje dva způsoby zápisu zanořených hodnot – a z tohoto důvodu ignorují atributy jakožto zbytečné (z teoretického pohledu skutečně zbytečné jsou) a snaží se používat jen podmnožinu z XML a dávat vše do elementů. Z teoretického a modelového pohledu to jednodušší je, z pohledu zápisu je to zase složitější. Osobně bych upřednostnil spíš ten praktičtější kompromis (elementy i atributy, které se lépe píší a čtou) než nějakou absolutní teoretickou čistotu formátu.

Většinou ale za tím žádná hluboká myšlenka nebude a je to spíš důsledek lenosti nebo ignorance. Ono špatně navržených nedomyšlených formátů postavených nad XML jsou spousty (což je i většina důvodů ke kritice XML – tzn. kritiku nezaslouží až tak XML jako takové, ale spíš některé formáty na něm postavené).

P.S. Určitě je lepší mít někde element, i když by stačil atribut, než mastit víc hodnot do jednoho atributu oddělených třeba čárkou nebo mezerou. Nebo taková zvěrstva jako atribut-1="" atribut-2="" atribut-2="" nebo dokonce „emulaci“ jmenných prostorů pomocí nějakých prefixů. Za taková zvěrstva by měl následovat krutý trest.

[Filip Jirsák]

Primárně používám elementy. Mohou se opakovat, mohu do nich vkládat další elementy, můžu je zakomentovat atd. Atributy chápu jako něco, co chci jen přidat k nějakému elementu, ale samotné to nemá smysl – typicky při použití XML pro značkování textu. To, že se u ukončovacího tagu musí opakovat název elementu, bych vůbec neřešil – od toho přece máme editory.

[Ondra Satai Nekola]

A je to primárně formát anotující text (jako html) nebo formát  pro serializaci dat?

[aaaaaa]

W3Schools : XML Elements vs. Attributes
https://www.w3schools.com/xml/xml_dtd_el_vs_attr.asp

IDM Developer Works : When to use elements versus attributes
https://www.ibm.com/developerworks/library/x-eleatt/index.html


happy reading 

[Reklama]

[Kit]

A je to primárně formát anotující text (jako html) nebo formát  pro serializaci dat?

Tohle je část konfiguráku pro Maven, tedy formát pro serializaci dat, který by vývojář mohl chtít číst a případně modifikovat - jenom jako příklad. Uvažoval jsem nad tím, jaký by mělo smysl použití více než jednoho elementu id, name, url, releases a snapshots. Podle mne žádný. Už jsem předělal dost nepřehledných struktur XML popsaným způsobem. Zpravidla přitom zmizelo dost značek, které tam neměly co pohledávat.

U anotovaného textu je pravidlo, že když se odstraní značky, mělo by být zachováno sdělení. To však není tento případ.

Dnes se dost rozmohlo používání formátů JSON a YAML, často na úkor XML. Důvodem je zpravidla tvrzení, že XML zabírá víc místa a je méně přehledné. Problém je však podle mne v tom že ti vývojáři už neumí XML ani vhodně navrhnout a tak použijí formát, který ani moc navrhovat nemusí a do kterého vlastně jen nasypou data. Přitom si neuvědomují, že tím vzniká technologický dluh.

[Kit]

Používám jak elementy, tak atributy. Atributy jsou stručnější a přehlednější, ale můžeš u nich v budoucnu narazit. Základní pravidlo je: bude tu vždy ta hodnota jen jednou a bude atomická? Pokud je odpověď jednoznačné ano, tak není problém z toho udělat atribut. Pokud nevím nebo plánuji rozšíření (podpora více prvků nebo nějaké vnitřní členění, doplnění atributu k atributu), tak spíš element.

Toho jsem si vědom. Právě tím atributem bych rád zvýraznil, že ta hodnota smí být pouze jednou.

Pokud by však atribut byl například cena="42" a k tomu jednotka="CZK", tak by to už mohl být problém.

P.S. Určitě je lepší mít někde element, i když by stačil atribut, než mastit víc hodnot do jednoho atributu oddělených třeba čárkou nebo mezerou. Nebo taková zvěrstva jako atribut-1="" atribut-2="" atribut-2="" nebo dokonce „emulaci“ jmenných prostorů pomocí nějakých prefixů. Za taková zvěrstva by měl následovat krutý trest.

Setkal jsem se i s protipólem, tedy s elementy foto1, foto2, foto3. V nich byly elementy url a name. Hnus. Přitom se to dalo krásně umístit do tří elementů foto s atributy id, url a name.

[Kit]

W3Schools : XML Elements vs. Attributes
https://www.w3schools.com/xml/xml_dtd_el_vs_attr.asp
IDM Developer Works : When to use elements versus attributes
https://www.ibm.com/developerworks/library/x-eleatt/index.html
happy reading 

Tohle už mám za sebou, spíš se ptám na osobní preference.

[anonym]

MÁM ŘEŠENÍ! Jako vždy 

Není to náhodou v konfigrácích Springu tak, že máš atribut "ref", napr "ref="mojeBeana"", ale druha moznost jak zadat ref je pres inner text?

To dava smysl. Tzn diky tomu si ty sam muzes rozhodnout, jestli pouzijes ref a nebo inner text popř. inner element. Kdyz mas obyc String, das do do ref. Kdyz mas nejakou vlastnost ve slozenych zavorkach, tj odkazuje se to na properies file, das to do inner text. A kdyz ma byt ref slozeny typ, das to jako inner element.

Ma to hlavu a patu, je to konzistentni.

[palo]

Už s XML delší dobou nedělám (byl to jeden čas můj denní chléb) ale myslím že někteří předřečníci to vystihli správně. Koneckonců i ty názvy “atribut” a “element” napovídají…

“atribut” typicky jednoduchá nestrukturovaná hodnota (číslo, krátký string /label, tag/, výčtová hodnota), doslova “vlastnost elementu”.

“element” - plnotučná “zanořená” strukturovaná nebo “dlouhá (text)” věc.

Je to (dualita atribut × element, resp. atribut navíc k obecnému elementu) syntaktický cukr ale použit s rozumem data serializovaná do xml výrazně zpřehledňuje.

[SB]

...Problém je však podle mne v tom že ti vývojáři už neumí XML ani vhodně navrhnout a tak použijí formát, který ani moc navrhovat nemusí a do kterého vlastně jen nasypou data. Přitom si neuvědomují, že tím vzniká technologický dluh.

Technologický dluh??? Tohle budete muset vysvětlit. A dokud nebude zcela jasně definovaný smysl atributu, tak to půjde těžko. Myslel jsem, že formát, do kterého se "jen nasypou data", je cílem.

[Kit]

...Problém je však podle mne v tom že ti vývojáři už neumí XML ani vhodně navrhnout a tak použijí formát, který ani moc navrhovat nemusí a do kterého vlastně jen nasypou data. Přitom si neuvědomují, že tím vzniká technologický dluh.

Technologický dluh??? Tohle budete muset vysvětlit. A dokud nebude zcela jasně definovaný smysl atributu, tak to půjde těžko. Myslel jsem, že formát, do kterého se "jen nasypou data", je cílem.

Vytrženo z kontextu formátů JSON a YAML, které jsou možná pohodlné, ale nejsou samopopisující. Kvůli nim vzniká ten technologický dluh.

[Demižon]

...Problém je však podle mne v tom že ti vývojáři už neumí XML ani vhodně navrhnout a tak použijí formát, který ani moc navrhovat nemusí a do kterého vlastně jen nasypou data. Přitom si neuvědomují, že tím vzniká technologický dluh.

Technologický dluh??? Tohle budete muset vysvětlit. A dokud nebude zcela jasně definovaný smysl atributu, tak to půjde těžko. Myslel jsem, že formát, do kterého se "jen nasypou data", je cílem.

Samozřejmě, ze je to technologický dluh. Rychle zmaštěná aplikace sice ušetří nějaký čas na začátku, ale následně se ti to vrátí. Někteří vývojáři si bohužel neuvedomuji, že navrhnout formát není totéž jako vybrat knihovnu pro serializaci. Nebo, že mavrhnout API není totéž jako zpřístupnit pro vzdálené volání par metod pomoci nějaké technologie.

[Kit]

Už s XML delší dobou nedělám (byl to jeden čas můj denní chléb) ale myslím že někteří předřečníci to vystihli správně. Koneckonců i ty názvy “atribut” a “element” napovídají…
“atribut” typicky jednoduchá nestrukturovaná hodnota (číslo, krátký string /label, tag/, výčtová hodnota), doslova “vlastnost elementu”.
“element” - plnotučná “zanořená” strukturovaná nebo “dlouhá (text)” věc.
Je to (dualita atribut × element, resp. atribut navíc k obecnému elementu) syntaktický cukr ale použit s rozumem data serializovaná do xml výrazně zpřehledňuje.

U mne ten vývoj byl opačný. Nejprve se mi XML moc nelíbil kvůli ukecanosti. Hledal jsem řešení typu INI, které v některých aplikacích stále používám, i když je zanoření omezeno na dvě úrovně. Hodně se mi líbil YAML pro maximální stručnost, ale nevýhodou je menší rozšíření parserů a generátorů. Když je v něm chyba, tak se hodně blbě hledá. Potom JSON, který má skvělé vlastnosti pro komunikaci s Javascriptem a některými NoSQL databázemi.

Jenže ze všeho nejlepší zůstává stále XML, u kterého jsou vyřešeny problémy, kterými předchozí formáty trpí. Při správném návrhu je také dobře čitelný, je validovatelný a dá se zpracovávat standardními nástroji. Jen je poslední dobou vývojáři poněkud opomíjený.

[Filip Jirsák]

Jenže ze všeho nejlepší zůstává stále XML, u kterého jsou vyřešeny problémy, kterými předchozí formáty trpí. Při správném návrhu je také dobře čitelný, je validovatelný a dá se zpracovávat standardními nástroji. Jen je poslední dobou vývojáři poněkud opomíjený.

No jo, jenže než na tohle většina lidí přijde, že to, co řeší s JSONem nebo YAML, má XML už dávno vyřešené, a že ty takzvané výhody JSONu nebo YAMLu jsou ve skutečnosti nevýhody…

Nejprve se mi XML moc nelíbil kvůli ukecanosti.

Tohle je zvláštní zcestná představa, kterou má ovšem spousta vývojářů – totiž že by jazyk (ať už programovací, formátovací nebo pro zápis strukturovaných dat) měl být maximálně stručný. Přitom si můžeme vzít za vzor přirozené jazyky, které přílišnou stručností rozhodně neoplývají. A to se lidský jazyk vyvinul z nějakých skřeků, takže se určitě rozvíjel od stručnosti směrem k rozvinutosti a redundanci. Už jenom tohle by mělo stačit k tomu, abychom si uvědomili, že určitá redundance v jazyce je pro člověka prospěšná (například proto, že nás při čtení utvrzuje v tom, že čteme správně).