it-swarm.dev

Mám používat prvky nebo atributy v XML?

Učím se o XML ​​atributech z W3Schools .

Autor zmiňuje následující:

Prvky XML vs. atributy

<person sex="female">
  <firstname>Anna</firstname>
  <lastname>Smith</lastname>
</person>

<person>
  <sex>female</sex>
  <firstname>Anna</firstname>
  <lastname>Smith</lastname>
</person>

V prvním příkladu je sex atributem. V posledním je sex prvkem. Oba příklady poskytují stejné informace.

Neexistují žádná pravidla o tom, kdy použít atributy a kdy použít prvky. Atributy jsou užitečné v HTML. V XML moje rada je vyhnout se jim. Místo toho použijte prvky. 

Vyhněte se atributům XML?

Některé problémy s používáním atributů jsou:

  • atributy nemohou obsahovat více hodnot (elementy mohou)
  • atributy nemohou obsahovat stromové struktury (elementy mohou)
  • atributy nejsou snadno rozšiřitelné (pro budoucí změny)

Atributy je obtížné číst a udržovat. Použijte prvky pro data. Použít atributy pro informace, které nejsou relevantní pro data.

Takže je pohled autora slavný, nebo je to nejlepší praxe v XML?

Měli byste se vyhnout atributům v XML?

W3Schools také zmínil následující (důlní důl): 

Atributy XML pro metadata

Někdy jsou jednotlivým prvkům přiřazeny odkazy na ID. Tato ID mohou být použita k identifikaci XML elementů stejně jako atribut ID v HTML. Tento příklad ukazuje:

<messages>
  <note id="501">
    <to>Tove</to>
    <from>Jani</from>
    <heading>Reminder</heading>
    <body>Don't forget me this weekend!</body>
  </note>
  <note id="502">
    <to>Jani</to>
    <from>Tove</from>
    <heading>Re: Reminder</heading>
    <body>I will not</body>
  </note>
</messages>

ID výše je pouze identifikátor, který identifikuje různé poznámky. Není součástí poznámky samotné.

Snažím se zde říci, že metadata (data o datech) by měla být uložena jako atributy a že data by měla být uložena jako prvky.

62
Ibn Saeed

O použití atributů nebo prvků obvykle rozhodují data, která se snažíte modelovat.

Pokud je například určitá entitaČ&AACUTE;STdat, pak je vhodné, aby byl prvek. Nedílnou součástí údajů o zaměstnancích je například jméno zaměstnance.

Nyní, pokud chcete sdělitMETADATAo datech (něco, co poskytuje další informace o datech), ale není opravdu součástí dat, pak je lepší, aby byl atribut. Pro Například, každý zaměstnanec má GUID potřebný pro zpracování zpětného konce, pak je jeho atribut lepší. (Identifikátor GUID není něco, co by poskytlo opravdu užitečné informace někomu, kdo se dívá na XML, ale může být nezbytný pro ostatní uživatele. účely)

Neexistuje žádné pravidlo, které říká, že něco by mělo být atributem nebo elementem.

Není nutné, aby se AVOID atributy za každou cenu .. Někdy jsou jednodušší model, než prvky. To záleží na údajích, které se snažíte reprezentovat.

53
Prashanth

V neposlední řadě je důležité, aby vkládání věcí do atributů znamenalo méně podrobný XML.

Porovnejte

<person name="John" age="23" sex="m"/>

Proti

<person>
    <name>
        John
    </name>
    <age>
        <years>
            23
        </years>
    </age>
    <sex>
        m
    </sex>
</person>

Ano, to bylo trochu zkreslené a přehnané, ale máte na to smysl

19
flybywire

Moje 0,02 pět let po OP je přesný opak. Nech mě to vysvětlit. 

  1. Použijte elementy, když seskupujete podobná data a atributy , Která data. 
  2. Nepoužívejte prvky pro všechno. 
  3. Pokud se data opakují (1 až mnoho), je to pravděpodobně prvek
  4. Pokud se data nikdy neopakují a mají smysl pouze tehdy, když se vztahují k Něčemu jinému, je to atribut.
  5. Pokud data nemají jiné atributy (tj. Jméno), pak je to atribut
  6. Seskupte podobné prvky společně, aby podpořily syntaktické analýzy (tj./Xml/znak)
  7. Opětovné použití podobných názvů prvků pro podporu analýzy dat 
  8. Nikdy, nikdy , nepoužívejte čísla v názvech prvků k zobrazení pozice. (tj. character1, character2) Tato praxe dělá to velmi těžké analyzovat (vidět # 6, analyzovat kód musí/charakter1,/charakter2, etc. ne jednoduše/charakter.

Zvažováno jinak:

  • Začněte přemýšlením o všech vašich datech jako atributu.
  • Logicky seskupte atributy do elementů. Pokud znáte svá data, budete muset zřídka převést atribut na prvek. Pravděpodobně už víte, kdy je nutný prvek (sběr nebo opakovaná data)
  • Logicky seskupte prvky
  • Když narazíte do případu, který potřebujete rozšířit, přidejte nové prvky/atributy založené na logické struktuře procesu výše. Přidání nové kolekce podřízených prvků nebude váš návrh „přerušovat“ a časem bude snazší číst.

Když se například podíváme na jednoduchou sbírku knih a hlavních postav, titul nikdy nebude mít „děti“, je to jednoduchý prvek. Každá postava má jméno a věk.

    <book title='Hitchhiker&apos;s Guide to the Galaxy' author='Douglas Adams'>
        <character name='Zaphod Beeblebrox' age='100'/>
        <character name='Arthur Dent' age='42'/>
        <character name='Ford Prefect' age='182'/>
    </book>

    <book title='On the Road' author='Jack Kerouac'>
        <character name='Dean Moriarty' age='30'/>
        <character name='Old Bull Lee' age='42'/>
        <character name='Sal Paradise' age='42'/>
    </book>

Dalo by se namítnout, že kniha mohla mít více autorů. OK, stačí rozbalit přidáním nových elementů autora (případně odstranit původní @author). Jistě, porušili jste původní strukturu, ale v praxi je to velmi vzácné a snadno se s ní pracuje. Každý spotřebitel vašeho původního XML, který předpokládal jednoho autora, se bude muset stejně změnit (je pravděpodobné, že změní svůj DB, aby přesunul autora ze sloupce v tabulce „knihy“ na tabulku „autora“).

<book title='Hitchhiker&apos;s Guide to the Galaxy'>
    <author name='Douglas Adams'/>
    <author name='Some Other Guy'/>
    <character name='Zaphod Beeblebrox' age='100'/>
    <character name='Arthur Dent' age='42'>
    <character name='Ford Prefect' age='182'/>
</book>
18
William Walseth

Použil jsem Google k vyhledání přesné otázky. Nejprve jsem přistál na tomto článku, http://www.ibm.com/developerworks/library/x-eleatt/index.html . Ačkoli to bylo příliš jednoduché na jednoduchou otázku jako takovou. Každopádně jsem četl všechny odpovědi na toto téma a nenašel jsem uspokojivé shrnutí. Jako takový jsem se vrátil k tomuto článku. Zde je shrnutí:

Kdy používám prvky a kdy používám atributy pro prezentaci bitů informací?

  • Pokud by daná informace mohla být označena prvky, vložte ji do prvku.
  • Pokud je informace vhodná pro formulář atributu, ale mohla by skončit jako více atributů stejného jména na stejném prvku, použijte místo něj podřízené prvky.
  • Pokud je požadováno, aby informace byly ve standardním typu atributu typu DTD, například ID, IDREF nebo ENTITY, použijte atribut.
  • Pokud by informace neměly být normalizovány pro prázdné místo, použijte prvky. ( XML ​​procesory normalizují atributy způsoby, které mohou změnit surový text hodnoty atributu.)

Princip obsahu jádra

Považujete-li dotyčné informace za součást Základního materiálu, který je vyjádřen nebo sdělován v XML, vložte jej do prvku. Považujete-li informace za periferní Nebo za nápovědu k hlavnímu sdělení, nebo pouze za účelem pomoci Aplikacím zpracovat hlavní komunikaci, použít atributy.

Princip strukturovaných informací

Pokud jsou informace vyjádřeny ve strukturované podobě, zejména pokud může být struktura roztažitelná, použijte prvky. Pokud je informace Vyjádřena jako atomový token, použijte atributy.

Princip čitelnosti

Je-li informace určena k přečtení a porozumění osobě, použije Prvky. Pokud jsou tyto informace nejsnáze pochopitelné a Stráveny strojem, použijte atributy.

Princip vazby prvku/atributu

Použijte prvek, pokud potřebujete, aby jeho hodnota byla změněna jiným atributem . [..] je téměř vždy hrozný nápad mít jeden atribut změnit jiný.

Toto je krátké shrnutí důležitých bitů z článku. Pokud chcete vidět příklady a úplný popis každého případu, pak se podívejte na původní článek. 

10
Gajus

Mapování atributů modelu. Množina atributů na elementu se přímo mapuje na mapu názvu/hodnoty, ve které jsou hodnoty text nebo jakýkoliv typ serializovatelné hodnoty. Například v jazyce C # může být libovolný objekt Dictionary<string, string> reprezentován jako seznam atributů XML a naopak.

To se v žádném případě nezdá být u prvků. I když můžete vždy přeměnit mapu názvu/hodnoty na množinu prvků, opak není případ, např .:

<map>
   <key1>value</key1>
   <key1>another value</key1>
   <key2>a third value</key2>
</map>

Pokud to převedete na mapu, ztratíte dvě věci: více hodnot spojených s key1 a skutečnost, že key1 se objeví před key2.

Význam tohoto je mnohem jasnější, pokud se podíváte na kód DOM, který se používá k aktualizaci informací ve formátu, jako je tento. Například je triviální napsat toto:

foreach (string key in map.Keys)
{
   mapElement.SetAttribute(key, map[key]);
}

Tento kód je stručný a jednoznačný. Naproti tomu řekněme:

foreach (string key in map.Keys)
{
   keyElement = mapElement.SelectSingleNode(key);
   if (keyElement == null)
   {
      keyElement = mapElement.OwnerDocument.CreateElement(key);
      mapElement.AppendChild(keyElement);
   }
   keyElement.InnerText = value;
}
5
Robert Rossney

Nelze umístit CDATA do atributu. Podle mých zkušeností, dříve nebo později, budete chtít dát jednotlivé uvozovky, dvojité uvozovky a/nebo celé XML dokumenty do "člena", a pokud je to atribut, který budete nadávat na osobu, která místo toho použila atributy prvků.

Poznámka: mé zkušenosti s XML se týkaly hlavně čištění ostatních lidí. Zdálo se, že tito lidé sledují staré pořekadlo „XML je jako násilí. Pokud ho nevyřešil váš problém, pak jste nepoužili dost.“

3
Coxy

Vše záleží na tom, pro co se XML používá. Když je to většinou interop mezi softwarem a stroji - jako jsou webové služby, je snazší jít se všemi prvky, pouze pokud jde o konzistenci (a také některé rámce to dávají přednost, např. WCF). Pokud je zaměřen na lidskou spotřebu - tj. Primárně vytvořený a/nebo čtený lidmi - pak může rozumné používání atributů poměrně dobře zlepšit čitelnost atributů; XHTML je rozumný příklad toho, a také XSLT a XML schéma.

3
Pavel Minaev

Obvykle pracuji na základě toho, že atributy jsou metadata - tedy data o datech. Jedna věc, kterou jsem se vyhnout, je uvedení seznamů v atributech. např. 

attribute="1 2 3 7 20"

V opačném případě máte k dispozici další úroveň analýzy pro extrahování každého prvku. Pokud XML poskytuje strukturu a nástroje pro seznamy, pak proč sami ukládat další.

Jeden scénář, kde chcete kód přednostní pro atributy, je pro rychlost zpracování pomocí analyzátoru SAX. Pomocí analyzátoru SAX získáte zpětné volání prvku obsahující název prvku a seznam atributů. Pokud jste namísto toho použili více prvků, získáte více zpětných volání (jedno pro každý prvek). Kolik z břemene/časového limitu je samozřejmě na diskusi, ale možná stojí za zvážení.

3
Brian Agnew

Toto je příklad, kdy atributy jsou data o datech.

Databáze jsou pojmenovány podle atributu ID.

Atribut "typ" databáze označuje to, co se očekává, že se nachází uvnitř tagu databáze.

  <databases>

      <database id='human_resources' type='mysql'>
        <Host>localhost</Host>
        <user>usrhr</user>
        <pass>jobby</pass>
        <name>consol_hr</name>
      </database>

      <database id='products' type='my_bespoke'>
        <filename>/home/anthony/products.adb</filename>
      </database>

  </databases>
2
Anthony Scaife

Body autora jsou správné (kromě toho, že atributy mohou obsahovat seznam hodnot). Otázkou je, zda vám záleží na jeho bodech. 

Je to na tobě.

2
John Saunders

Je to kvůli tomu druhu odpadu, kterému byste se měli vyhnout w3schools. Pokud něco, je to ještě horší než děsivé věci, které mají o JavaScriptu.

Jako obecné pravidlo bych navrhl, aby obsah - tj. Data, u nichž se očekává, že budou spotřebovány koncovým uživatelem (ať už jde o lidské čtení nebo o stroj přijímající informace pro zpracování) - byl nejlépe obsažen v prvku. Metadata - například ID přidružené k obsahu, ale pouze hodnota pro interní použití, nikoli pro zobrazení koncovému uživateli - by měla být v atributu.

0
NickFitz

Pravděpodobně byste mohli tento problém vidět sémanticky.

Pokud jsou data těsněji spojena s prvkem, bude to atribut. 

tj. ID prvku, uvedl bych ho jako atribut prvku.

Ale je pravda, že při analýze dokumentu mohou atributy dokumentu způsobit více bolestí hlavy než prvky.

Vše záleží na vás a na tom, jak navrhujete schéma.

0
HyLian

Zde je další věc, kterou je třeba mít na paměti při rozhodování o formátu XML: Pokud si vzpomínám správně, hodnoty atributů "id" nesmí být všechny číselné, musí splňovat pravidla pro názvy v XML. Hodnoty samozřejmě musí být jedinečné. Mám projekt, který musí zpracovávat soubory, které tyto požadavky nesplňují (i když jsou to čisté XML v jiných ohledech), což způsobilo, že zpracování souborů bylo spletitější.

0
Grimarr