Quale scegliere: attributo XML o sub nodo?

Non esiste una chiara documentazione / best practice per questo, ma, considerate le alternative, come avete:

Come elemento testo:

• può essere più facile visualizzare i dati come xhtml, ecc., dove il contenuto del testo è considerato testo, piuttosto che markup o meta-dati.
• ci possono essere più di uno. Se hai bisogno di contenuti secondari con più età o righe di nomi, gli attributi non permetteranno questo
• se hai bisogno di metadati a livello di riga, hai la possibilità di utilizzare gli attributi di <name> o <age> per questo scopo

Attributi:

• l'XML è più compatto
• XSLT e DocTypes sono più semplici da specificare
• non ti devi preoccupare degli spazi bianchi (padding, indenting, interruzioni di riga) o di altri elementi che possono essere introdotti (commenti, PI) nelle aree PCDATA (testo elemento)
• ce ne può essere solo uno! non devi preoccuparti del contenuto secondario che contiene più attributi age .

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

Principi del design 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 è possibile cambiarli o modificarli o annidarli. Sono indipendenti dall'ordine e distinti all'interno dell'elemento (non puoi avere due della stessa cosa).

Se uno qualsiasi 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 primo, secondo nome e cognome ... e un soprannome. E alcune persone hanno nomi da nubile, più nomi di mezzo o onorifici - come metteresti in John Ronald Reuel Tolkien in una tale struttura?

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

_{Non riesco a trovarlo attualmente, ma nel documento sopra collegato c'è una dichiarazione secondo cui i nomi sono cose che richiedono un po 'di riflessione che portano a "Spero di espandere il trattamento dei nomi delle persone in markup in un articolo futuro. " Se qualcuno ha un ruolo guida 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 intero). In quanto tale, la rappresentazione di queste informazioni in un formato ben noto e compreso ha senso in un attributo. Una persona ha uno e solo un compleanno e non esiste un 'ordine' che desideri conservare.

Uche Ogbuji identifica tre principi fondamentali nella corretta progettazione di un formato xml. Le seguenti sono citazioni abbreviate dal documento collegato sopra.

• Principio delle informazioni strutturate
  Se l'informazione è espressa in una forma strutturata, specialmente se la struttura può essere estensibile, utilizzare gli elementi. D'altra parte: se l'informazione è espressa come un token atomico, usa gli attributi
• Principio della leggibilità
  Se l'informazione è intesa per essere letta e compresa da una persona, utilizzare gli elementi. Se le informazioni sono più facilmente comprensibili e digerite da una macchina, utilizzare gli attributi.
• Principio del collegamento elemento / attributo
  Usa un elemento se hai bisogno che il suo valore sia modificato da un altro attributo

E così, i nomi dovrebbero essere elementi - sono dati strutturati che non sono un token atomico, hanno più probabilità di essere letti da un 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ù probabilmente letti da un computer che da un essere umano (e quindi trasformato nel formato preferito dall'essere umano se necessario ) e, infine, è improbabile che vengano modificati da altri attributi su di essi.

Un'altra considerazione tra quelle di Rolfl è il numero di campi.
Più di un piccolo numero di attributi diventa un casino e difficile da leggere (supponendo che tu voglia che il tuo xml sia leggibile da un punto di vista umano, ma come programmatore vorrai farlo per testare almeno).
< br> Inoltre, se si prevede che la struttura dei dati di uno dei campi cambi nel tempo, non trasformarla in un attributo.
Ad esempio, il tuo campo nome. Forse in futuro questo diventerebbe

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

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

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

La storia è diversa per Persona e i suoi componenti. Una persona non contiene un nome, il nome è un attributo della persona, quindi rimango con attributi anziché nuovi tag. I tag sono utili quando hai cose ripetitive come Addresses, non puoi farlo con gli attributi.

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