Come si dovrebbe strutturare il file xml?

Question

Quando si crea un nuovo file xml, come si fa a strutturare il file correttamente o nel modo migliore possibile. Per struttura, che potrebbe non essere la parola migliore in questo caso, voglio dire come si fa a scegliere tra fare qualcosa di un elemento o un attributo di un elemento. Ad esempio, se creo un file Person.xml che contiene un elenco delle persone, è meglio fare qualcosa di simile:

<Person> 
    <FirstName>John</FirstName> 
    <LastName>Doe</LastName> 
    <Age>23</Age> 
</Person> 

o è meglio fare qualcosa di simile o ha addirittura importa?

<Person FirstName="John" LastName="Doe" Age="23"></Person> 

Answer 1

file XML dovrebbe (non iniziare una guerra santa) essere strutturato come segue:

Se si tratta di dati, o qualcosa che può essere modificato, allora dovrebbe essere simile a questo:

<Person> 
    <FirstName>John</FirstName> 
    <LastName>Smith</LastName> 
    <Age>23</Age> 
</Person> 

Se si tratta di un attributo della cosa Person allora dovrebbe essere simile a questo:

ci sono diverse ragioni per questa pratica, non ultimo dei quali comprende la facilità di f ixing delle tue trasformazioni XSLT ogni volta che cambi il metodo di recupero dei dati Person.

Questa è davvero la parte importante: gli attributi definiscono le informazioni sui dati (il tipo di persona), e i dati sono qualcosa che è pensato per riempire quei buchi. Se decidi come cambierai il modo in cui inserisci questi buchi, diventa più difficile se li hai creati "attributi" invece di "dati" quando vuoi trasformare il tuo XML più tardi.

Answer 2

È praticamente una cosa soggettiva.

Answer 3

Davvero non importa, ma il modo in cui decido è: se qualcosa può essere considerato un'entità a sé stante (in questo esempio, Person, ne faccio un elemento.) Se è qualcosa che modifica l'entità (o attributo del soggetto), mi fanno un attributo

Esempio:.

<Person FirstName="John" LastName="Doe" Age="23"> 
    <Clothing wet="No"> 
     <Shirt colour="Red" /> 
    </Clothing> 
</Person> 

Answer 4

mi sembra questo è qualcosa di simile a Chevy vs Ford, o Windows vs Mac OS non v'è alcun chiaro vincitore per tutti. situazioni, e la semplice domanda può generare una "discussione" altamente volatile con i partecipanti giusti.;)

La risposta breve è che può essere appropriato a seconda della situazione. A volte il fattore decisivo è anche la libreria scelta per leggere o aggiornare i dati nell'XML.

Answer 5

Ecco una pretty good article sulle princeiples del design XML:

• Principles of XML design: When to use elements versus attributes

Answer 6

Il primo è il modo di fare le cose verbose: Tutto è un elemento. Questo è un modo comune in cui le persone lo fanno semplicemente perché è così facile da guardare e analizzare.

Tuttavia, gli attributi sono stati introdotti proprio per questo motivo: sono bit di informazioni sull'elemento. Quindi, il tuo secondo esempio è perfettamente accettabile.In realtà, si potrebbe anche accorciare:

<Person FirstName="John" LastName="Doe" Age="23" /> 

avrei probabilmente fare il secondo.

L'unica volta che non lo si desidera è se è necessario disporre di più dati xml all'interno o sezioni lunghe formattate.

Answer 7

In generale, si desidera che gli elementi rappresentino le informazioni "reali" che si stanno modellando e riservano gli attributi per le informazioni "meta" che qualificano il contenuto.

Answer 8

Indipendentemente dal gusto personale, qui è l'insieme fondamentale di problemi:

utilizzare gli attributi per mappare i valori di nomi univoci in fase d'ordine non è significativo. Altrimenti, usa gli elementi.

• Valori: numeri, stringhe, date, ecc., Ma non oggetti multi-proprietà.
• Nome univoco: ogni nome di attributo su un elemento deve essere univoco. Se una cosa rappresentata da un elemento può avere più di una Foo ad essa associata, Foo non dovrebbe essere un attributo.
• L'ordine non è significativo: l'applicazione non può dipendere dai valori presentati ai processi in un ordine particolare.

Un esempio: se si desidera eseguire il round-trip dei dati tra (ad esempio) ADO.NET e XML, è necessario memorizzare i valori delle colonne in attributi o elementi? (Non importa per un momento che ADO.NET faccia questo per te.) Bene, i nomi delle colonne mappano i valori in modo univoco ei valori delle colonne sono tipi di dati facilmente serializzabili. Quindi, sicuro, perché non farlo?

<Person FirstName="John" MiddleName="Q." LastName="Smith"/> 

Ma in realtà questa è una trasformazione che distrugge le informazioni. L'ordine in cui le colonne vengono visualizzate in un record ADO.NET è significativo. Se qualcosa è nella colonna 2 prima della trasformazione, dovrebbe essere in seguito nella colonna 2. La loro conversione in attributi perderà queste informazioni. (So ​​che un'implementazione DOM, per esempio, che recupera gli attributi in ordine alfabetico per nome.)

Questo è il motivo per ADO.NET rappresenta righe come questo, anche se è verbose:

<Person> 
    <FirstName>John</FirstName> 
    <MiddleName>Q.</MiddleName> 
    <LastName>Smith</LastName> 
</Person> 

Per quanto riguarda il opinione comune che gli elementi sono per informazioni, e gli attributi sono per metainformazione: questo è spesso molto buoni consigli. Spesso è anche solo la superstizione che ti porterà in posti brutti.

Per uno, metainformation potrebbe dover contenere più valori associati con lo stesso nome. Si potrebbe, per esempio, vuole contrassegnare un elemento con un elenco di pagine che lo utilizzeranno:

<Person Pages="B1,B2,B3,B4"> 
    <FirstName>John... 

mai provato a scrivere un modello XSLT che analizza un elenco separato da virgole? Imparerete molto da fare, ma probabilmente non è qualcosa che si desidera sapere.

Per un altro, i progettisti di XML che non sanno cosa stanno facendo contro lasciare che questo consiglio li portano a mettere in un attributo ciò che in realtà dovrebbe essere nel nome del tag dell'elemento. Ad esempio:

<Person Type="Employee"> 
    <SSN>123-45-6789</SSN> 
    <Extension>123</Extension> 
</Person> 
<Person Type="Customer"> 
    <PhoneNumber>123-456-7890</PhoneNumber> 
    <BillingAddress>... 

e così via.Indovina cosa succede quando provi a scrivere uno schema che impone regole diverse sugli elementi Person in base all'attributo Type? Fallimento. Gli schemi sono legati al nome dell'elemento. Tutti gli elementi Person devono avere lo stesso schema. In questo caso, gli elementi dovrebbero essere denominati Employee e Customer.