Quale scegliere: attributo XML o nodo secondario?

Vogliamo esportare alcuni dati dalla nostra base di dati come XML. Ad esempio, una Personpuò avere age, namee alcune altre proprietà.

Abbiamo due scelte per definire il formato XML.

Scelta n. 1:

<Persons>
   <Person>
       <Age>16</Age>
       <Name>Richard</Name>
   </Person>
   <Person>
       <Age>34</Age>
       <Name>Eric</Name>
   </Person>
   ...
</Persons>

Scelta n. 2:

<Persons>
   <Person Age="16" Name="Richard"/>
   <Person Age="34" Name="Eric"/>
   ...
</Persons>

Quindi qual è la differenza tra la definizione di nodo secondario o attributo? E qual è il vantaggio di ogni scelta?

Non esiste una documentazione chiara / best practice per questo, ma, considera le alternative, in quanto hai:

Come testo dell'elemento:

• può essere più semplice visualizzare i dati come xhtml, ecc., in cui il contenuto del testo è considerato testo, anziché markup o metadati.
• può essercene più di uno. Se hai bisogno di contenuti secondari con più righe di età o nome, gli attributi non lo consentono
• se hai bisogno di metadati a livello di riga, hai la possibilità di utilizzare gli attributi di <name>o <age>per questo scopo

Come attributi:

• l'XML è più compatto
• XSLT e DocTypes sono più semplici da specificare
• non devi preoccuparti di spazi bianchi (riempimento, rientro, interruzioni di riga) o altri elementi che possono essere introdotti (commenti, PI) nelle aree PCDATA (testo dell'elemento)
• Può essercene solo uno! non devi preoccuparti del contenuto secondario contenente più ageattributi.

Ho trascorso molto tempo a lavorare con XML e, a mio avviso, per la pura comunicazione dei dati, gli attributi dovrebbero essere usati ogni volta che è possibile. Se è probabile che l'XML venga utilizzato per la presentazione (XSLT, xhtml, ecc.), Potrebbe essere migliore come contenuto del testo (ma non necessariamente).

Principi di progettazione XML: quando utilizzare gli elementi rispetto agli attributi di Uche Ogbuji di IBM è probabilmente una delle migliori risorse in materia.

Al centro della decisione è che gli attributi sono cose "fatte". Non puoi cambiarli o modificarli o nidificarli. Sono indipendenti dall'ordine e distinti all'interno dell'elemento (non puoi avere due della stessa cosa).

Se uno di questi vincoli è qualcosa che può cambiare, rendere i dati un nodo figlio dell'XML.

Nel tuo esempio, hai una persona che ha un nome e un'età. Ho un nome, un secondo e un cognome ... e un soprannome. E alcune persone hanno nomi da nubile, più nomi secondari o onorificenze: come inseriresti John Ronald Reuel Tolkien in una struttura del genere?

E così abbiamo qualcuno che ha due secondi nomi che hanno un ordine per loro. Ciò dovrebbe mostrare chiaramente che no, un attributo non è la scelta migliore per questo.

_{Non riesco a trovarlo attualmente, ma nel documento collegato sopra c'è un'affermazione che i nomi sono cose che richiedono un po 'di pensiero che porta a "Spero di espandere il trattamento dei nomi delle persone in markup in un prossimo articolo". Se qualcuno ha un vantaggio su questo, si prega di lasciare un commento o modificarlo in questo punto.}

D'altra parte, l'età è qualcosa che ha una struttura piuttosto fissa (suggerirei il compleanno piuttosto che un numero intero). Come tale, rappresentare queste informazioni in un formato ben noto e compreso ha senso in un attributo. Una persona ha uno, e solo un compleanno e non c'è nessun "ordine" che vuoi preservare.

Uche Ogbuji identifica tre principi fondamentali nella progettazione corretta di un formato XML. Di seguito sono citazioni abbreviate dal documento collegato sopra.

• Principio delle informazioni strutturate
  Se le informazioni sono espresse in una forma strutturata, specialmente se la struttura può essere estensibile, utilizzare gli elementi. D'altra parte: se le informazioni sono espresse come token atomico, utilizzare gli attributi
• Principio di leggibilità
  Se le informazioni devono essere lette e comprese da una persona, utilizzare gli elementi. Se le informazioni sono più facilmente comprese e digerite da una macchina, utilizzare gli attributi.
• Principio dell'associazione elemento / attributo
  Utilizzare un elemento se è necessario che il suo valore sia modificato da un altro attributo

E quindi, i nomi dovrebbero essere elementi: sono dati strutturati che non sono un token atomico, hanno maggiori probabilità di essere letti da un essere umano che da un computer e possono essere modificati da un altro attributo sul nome stesso.

Le date dovrebbero essere attributi: sono dati che sono un token atomico, sono più probabili la lettura da un computer rispetto a un essere umano (e quindi trasformati nel formato preferito dell'essere umano se necessario ), e infine è improbabile che vengano modificati da altri attributi su di loro.

Un'altra considerazione di quelli di beyong rolfl è il numero di campi.
Più di un piccolo numero di attributi diventa un disastro e difficile da leggere (questo presuppone che tu voglia che il tuo XML sia leggibile dall'uomo, ma come programmatore vorrai farlo almeno per i test).

Inoltre, se si prevede che la struttura dei dati di uno dei campi cambi nel tempo, non renderlo un attributo.
Ad esempio, il campo del tuo nome. Forse in futuro questo sarebbe diventato

<name>
  <firstName>George</firstName>
  <lastName>Orwell</lastName>
  <maidenName></maidenName>
  <nickName>Robert</nickName>
</name>

Se ti aspetti che accada qualcosa del genere, renderlo un attributo significherebbe più codice di refactoring in seguito.

Per il tag Persone, è normale avere più tag di Persona, ha senso, un elenco di Persone ha alcune entità, non attributi.

La storia è diversa per Person e le sue componenti. Una persona non contiene un nome, il nome è un attributo della persona, quindi rimarrei con attributi invece di nuovi tag. I tag sono utili quando hai cose ripetitive come Indirizzi, non puoi farlo con gli attributi.

Se pensiamo nel contesto HTML, non hai un input con un tag con un valore, vero?