Attributo XML vs elemento XML

StackOverflow https://stackoverflow.com/questions/33746

  •  09-06-2019
  •  | 
  •  

Domanda

Al lavoro ci viene chiesto di creare un file XML per passare i dati da un'altra applicazione offline che sarà quindi creare un secondo file XML di passare di nuovo per aggiornare alcuni dei nostri dati.Durante il processo di cui abbiamo parlato con la squadra per l'altra domanda circa la struttura del file XML.

L'esempio che ho scelto è essenzialmente qualcosa di simile:

<INVENTORY>
   <ITEM serialNumber="something" location="something" barcode="something">
      <TYPE modelNumber="something" vendor="something"/> 
   </ITEM>
</INVENTORY>

L'altra squadra, ha detto che questo non era standard del settore e che gli attributi devono essere utilizzati solo per meta dati.Hanno suggerito:

<INVENTORY>
   <ITEM>
      <SERIALNUMBER>something</SERIALNUMBER>
      <LOCATION>something</LOCATION>
      <BARCODE>something</BARCODE>
      <TYPE>
         <MODELNUMBER>something</MODELNUMBER>
         <VENDOR>something</VENDOR>
      </TYPE>
   </ITEM>
</INVENTORY>

Il motivo per cui ho suggerito la prima è che la dimensione del file creato è molto più piccolo.Ci saranno circa 80000 elementi che saranno nel file durante il trasferimento.Il loro suggerimento, in realtà, risulta essere tre volte più grande rispetto a quella che ho suggerito.Ho cercato la misteriosa "Industry Standard" che è stato menzionato, ma il più vicino che ho trovato è che gli attributi XML deve essere utilizzato solo per meta dati, ma ha detto che il dibattito su ciò che è stato effettivamente meta dati.

Dopo le lunghe e noiose spiegazioni (scusate) come si fa a determinare che cosa è meta dati, e durante la progettazione della struttura di un documento XML come si dovrebbe decidere quando utilizzare un attributo o un elemento?

È stato utile?

Soluzione

Io uso questa regola:

  1. Un Attributo è qualcosa che è indipendente, cioè, un colore, un ID, un nome.
  2. Un Elemento è una cosa che fa o che potrebbero avere gli attributi della propria o contenere altri elementi.

Quindi la tua è vicino.Io avrei fatto qualcosa di simile:

MODIFICA:Aggiornato l'esempio originale, in base al feedback di seguito.

  <ITEM serialNumber="something">
      <BARCODE encoding="Code39">something</BARCODE>
      <LOCATION>XYX</LOCATION>
      <TYPE modelNumber="something">
         <VENDOR>YYZ</VENDOR>
      </TYPE>
   </ITEM>

Altri suggerimenti

Alcuni dei problemi con gli attributi sono:

  • gli attributi non può contenere più valori (elementi del bambino può)
  • gli attributi non sono facilmente espandibile (per il futuro)
  • attributi non possono descrivere strutture (elementi del bambino può)
  • gli attributi sono più difficili da manipolare da un codice di programma
  • i valori di attributo non è facile di testare contro un DTD

Se si utilizzano gli attributi come contenitori di dati, si finisce con documenti che sono difficili da leggere e conservare.Provare a utilizzare gli elementi per descrivere i dati.Utilizzare solo gli attributi di fornire informazioni che non sono rilevanti per i dati.

Non finire come questo (questo non è il modo in XML dovrebbe essere usato):

<note day="12" month="11" year="2002" 
      to="Tove" to2="John" from="Jani" heading="Reminder"  
      body="Don't forget me this weekend!"> 
</note>

Fonte: http://www.w3schools.com/xml/xml_dtd_el_vs_attr.asp

"XML" sta per "eXtensible Markup Lingua".Un linguaggio di markup implica che i dati di testo, marcato con i metadati sulla struttura o la formattazione.

XHTML è un esempio di XML utilizzato il modo in cui è stato destinato:

<p><span lang="es">El Jefe</span> insists that you
    <em class="urgent">MUST</em> complete your project by Friday.</p>

Qui, la distinzione tra elementi e attributi è chiaro.Elementi di testo che vengono visualizzati nel browser, e gli attributi sono le istruzioni su come per visualizzare (anche se ci sono un paio di tag che non funziona in questo modo).

La confusione nasce quando viene utilizzato XML non è un linguaggio di markup, ma come un serializzazione dei dati la lingua, in cui la distinzione tra "dati" e "metadati" è più vago.Quindi la scelta tra gli elementi e gli attributi più o meno arbitraria, tranne per le cose che non può essere rappresentato con gli attributi (vedi feenster risposta).

Elemento XML vs Attributo XML

XML è tutto su accordo. Prima rinviare eventuali schemi XML o convenzioni stabilite all'interno della vostra comunità o di settore.

Se siete veramente in una situazione di definire lo schema da terra, qui sono alcune considerazioni di carattere generale, che deve informare l' elemento vs attributo di decisione:

<versus>
  <element attribute="Meta content">
    Content
  </element>
  <element attribute="Flat">
    <parent>
      <child>Hierarchical</child>
    </parent>
  </element>
  <element attribute="Unordered">
    <ol>
      <li>Has</li>
      <li>order</li>
    </ol>
  </element>
  <element attribute="Must copy to reuse">
    Can reference to re-use
  </element>
  <element attribute="For software">
    For humans
  </element>
  <element attribute="Extreme use leads to micro-parsing">
    Extreme use leads to document bloat
  </element>
  <element attribute="Unique names">
    Unique or non-unique names
  </element>
  <element attribute="SAX parse: read first">
    SAX parse: read later
  </element>
  <element attribute="DTD: default value">
    DTD: no default value
  </element>
</versus>

Potrebbe dipendere dal tuo utilizzo.XML che viene utilizzato per rappresentare stuctured dati generati da un database può lavorare bene con, in definitiva, i valori di campo più attributi.

Tuttavia XML utilizzato come un messaggio di trasporto spesso sarebbe meglio con più elementi.

Per esempio, consente di dire che abbiamo avuto questo XML, così come proposto nella risposta:-

<INVENTORY>
   <ITEM serialNumber="something" barcode="something">
      <Location>XYX</LOCATION>
      <TYPE modelNumber="something">
         <VENDOR>YYZ</VENDOR>
      </TYPE>
    </ITEM>
</INVENTORY>

Ora vogliamo inviare l'elemento di un dispositivo per la stampa di codice a barre ha tuttavia c'è una scelta di tipi di codifica.Come facciamo a rappresentare il tipo di codifica necessari?Improvvisamente ci rendiamo conto, un po ' in ritardo, che il codice a barre non era un singolo automic valore, ma piuttosto, può essere qualificato con la codifica necessaria quando stampato.

   <ITEM serialNumber="something">
      <barcode encoding="Code39">something</barcode>
      <Location>XYX</LOCATION>
      <TYPE modelNumber="something">
         <VENDOR>YYZ</VENDOR>
      </TYPE>
   </ITEM>

Il punto è che a meno che tu la costruzione di un certo tipo di DTD o XSD lungo con uno spazio dei nomi per il fissaggio della struttura in pietra, si può essere meglio servita lasciando aperte tutte le opzioni.

IMO XML è più utile quando può essere piegato senza rompere il codice esistente utilizzando.

Utilizzare le seguenti linee guida nel mio schema di progettazione per quanto riguarda gli attributi vselementi:

  • Utilizzare gli elementi per una lunga esecuzione di testo (di solito quelli di una stringa o di normalizedString tipi)
  • Non utilizzare un attributo se c'è un gruppo di due valori (ad es.eventStartDate e eventEndDate) per un elemento.Nell'esempio precedente, ci dovrebbe essere un nuovo elemento per "evento" che può contenere la data di inizio e endDate attributi.
  • Affari Date, DateTime e numeri (ad es.conta, importo e tasso) dovrebbe essere elementi.
  • Non tempo di affari elementi come ultimo aggiornamento, la scadenza dovrebbe essere attributi.
  • Non commerciali di numeri, come ad esempio i codici hash e indici dovrebbero essere gli attributi.* Utilizzare elementi se il tipo complesso.
  • Utilizzare gli attributi se il valore è un tipo semplice e non ripetere.
  • xml:id e xml:lang devono essere attributi di riferimento lo schema XML
  • Preferiscono gli attributi quando tecnicamente possibile.

La preferenza per gli attributi fornisce le seguenti operazioni:

  • unico (l'attributo non può essere utilizzato più volte)
  • l'ordine non importa
  • la proprietà di cui sopra sono ereditabili (questo è qualcosa che il "tutto" il contenuto del modello non supporta l'attuale schema di lingua)
  • il bonus è che sono meno dettagliato e utilizzare meno banda, ma questo non è davvero un motivo per preferire gli attributi più elementi.

Ho aggiunto quando tecnicamente possibile perché ci sono momenti in cui l'uso di attributi non sono possibili.Per esempio, il set di attributi scelte.Per esempio l'uso (datainizio e datafine) xor (startTS e endTS) non è possibile con l'attuale schema di lingua

Se XML Schema inizia permettendo il "tutti" modello di contenuto per essere limitato o esteso, allora probabilmente cadere

Non c'è risposta universale a questa domanda (mi è stato pesantemente coinvolto nella creazione del W3C spec).XML può essere utilizzato per molti scopi - testo-come i documenti, i dati e dichiarativa di codice sono tre dei più comuni.Anche io lo uso molto come un modello di dati.Ci sono aspetti di queste applicazioni di cui attributi sono più comuni e altri in cui gli elementi del bambino sono più naturali.Ci sono anche caratteristiche di vari strumenti che rendono più facile o più difficile per il loro utilizzo.

XHTML è una zona dove gli attributi hanno un uso naturale (ad es.a class='pippo').Gli attributi non hanno alcun ordine, e questo può rendere più facile per alcune persone a sviluppare strumenti.OTOH attributi sono più difficili da digitare senza uno schema.Trovo anche nel namespace attributi (pippo:bar="zork") sono spesso più difficili da gestire in vari set di strumenti.Ma diamo un'occhiata ad alcune delle W3C lingue per vedere la miscela che è comune.SVG, XSLT, XSD, MathML sono alcuni esempi di noti lingue e tutti hanno una ricca fornitura di elementi e attributi.Alcuni linguaggi permettono addirittura di più-di-un-modo per farlo, ad esempio

<foo title="bar"/>;

o 

<foo>
  <title>bar</title>;
</foo>;

Si noti che questi NON sono equivalenti dal punto di vista sintattico e richiedono un esplicito sostegno a strumenti di elaborazione)

Il mio consiglio sarebbe quello di avere uno sguardo alla pratica comune nella zona più vicina alla vostra applicazione e tenere conto anche di quali strumenti si potrebbe desiderare di applicare.

Infine, assicurarsi che si differenziano spazi dei nomi degli attributi.Un po ' di XML sistemi (ad es.Linq) rappresentano gli spazi dei nomi come attributi dell'API.IMO questo è brutto e potenzialmente fonte di confusione.

In caso di dubbio, BACIO -- perché combinare elementi e attributi quando non si dispone di una chiara ragione per l'utilizzo di attributi.Se in seguito si decide di definire un XSD, che alla fine sarà più pulito bene.Quindi se si decide di generare una struttura di classe dal tuo XSD, che sarà più semplice di così.

i milioni di dollari!

prima di tutto, non preoccuparti troppo di prestazioni ora.sarete stupiti a quanto velocemente ottimizzato parser xml strappare attraverso xml.ancora più importante, qual è il tuo disegno per il futuro:XML si evolve, come sarà possibile mantenere l'accoppiamento e l'interoperabilità?

più concretamente, è possibile rendere il modello di contenuto di un elemento più complesso, ma è più difficile per estendere un attributo.

Utilizzare gli elementi di dati e attributi per i meta-dati (dati circa l'elemento di dati).

Se un elemento è visualizzato come un predicato nel selezionare le stringhe, è un buon segno che dovrebbe essere un attributo.Allo stesso modo, se un attributo non viene utilizzato come un predicato, allora forse non è utile meta dati.

Ricordate che XML è supposto per essere leggibile non leggibile e per i grandi documenti XML comprime molto bene.

Altri hanno parlato di come distinguere tra gli attributi da elementi, ma da un punto di vista più generale mettendo tutto in attributi, perché rende il codice XML risultante minore è sbagliato.

XML non è progettato per essere compatto, ma per essere portatile e leggibile.Se si desidera ridurre la dimensione dei dati in transito, quindi utilizzare qualcos'altro (come google buffer di protocollo).

Si tratta di capire in ogni modo, ma i tuoi colleghi sono di destra, nel senso che il file XML dovrebbe essere usato per "markup" o meta-dati i dati effettivi.Per la tua parte, hai ragione, è che a volte è difficile decidere dove tra la linea di meta-dati e dati per la modellazione del dominio in XML.In pratica, quello che voglio fare è far finta che nulla nel markup è nascosto, e solo i dati al di fuori del markup è leggibile.Il documento di rendere certo senso, in che modo?

XML è notoriamente ingombranti.Per il trasporto e l'immagazzinamento, la compressione è altamente raccomandato se si può permettere la potenza di elaborazione.XML comprime bene, a volte straordinariamente bene, a causa della sua ripetitività.Ho dovuto comprimere file di grandi dimensioni a meno del 5% della loro dimensione originale.

Un altro punto per sostenere la vostra posizione è che, mentre l'altra squadra sta discutendo di stile (che la maggior parte degli strumenti di XML gestirà un attributo documento facilmente come un#PCDATA documento) si stanno discutendo gli aspetti pratici.Se lo stile non può essere totalmente ignorato, meriti tecnici dovrebbero portare più peso.

Entrambi i metodi per la memorizzazione delle proprietà dell'oggetto sono perfettamente validi.Si dovrebbe partire da considerazioni pragmatiche.Prova a rispondere seguente domanda:

  1. Quale rappresentazione conduce a più rapida l'analisi dei dati\generazione?
  2. Quale rappresentazione porta di trasferimento dati più veloce?

  3. Non leggibilità importa?

    ...

È in gran parte una questione di preferenze.Io uso gli Elementi per il raggruppamento e attributi per i dati, ove possibile, per come la vedo io questo come più compatto rispetto all'alternativa.

Per esempio io preferisco.....

<?xml version="1.0" encoding="utf-8"?>
<data>
    <people>
         <person name="Rory" surname="Becker" age="30" />
        <person name="Travis" surname="Illig" age="32" />
        <person name="Scott" surname="Hanselman" age="34" />
    </people>
</data>

...Invece....

<?xml version="1.0" encoding="utf-8"?>
<data>
    <people>
        <person>
            <name>Rory</name>
            <surname>Becker</surname>
            <age>30</age>
        </person>
        <person>
            <name>Travis</name>
            <surname>Illig</surname>
            <age>32</age>
        </person>
        <person>
            <name>Scott</name>
            <surname>Hanselman</surname>
            <age>34</age>
        </person>
    </people>
</data>

Tuttavia, se ho dei dati che non rappresentano facilmente all'interno di dire 20-30 caratteri o contiene molte citazioni o altri personaggi che hanno bisogno di escape, quindi direi che è il momento di rompere gli elementi...possibilmente con CData blocchi.

<?xml version="1.0" encoding="utf-8"?>
<data>
    <people>
        <person name="Rory" surname="Becker" age="30" >
            <comment>A programmer whose interested in all sorts of misc stuff. His Blog can be found at http://rorybecker.blogspot.com and he's on twitter as @RoryBecker</comment>
        </person>
        <person name="Travis" surname="Illig" age="32" >
            <comment>A cool guy for who has helped me out with all sorts of SVn information</comment>
        </person>
        <person name="Scott" surname="Hanselman" age="34" >
            <comment>Scott works for MS and has a great podcast available at http://www.hanselminutes.com </comment>
        </person>
    </people>
</data>

Che ne dici di prendere vantaggio di il nostro duramente guadagnato oggetto di orientamento intuizione?Di solito trovo che sia dritto avanti a pensare che è un oggetto e che è un attributo dell'oggetto o l'oggetto di cui esso fa riferimento.

Qualunque sia intuitivamente ha senso, in quanto gli oggetti sono contenute in quanto elementi.I suoi attributi (o proprietà) sarebbero gli attributi di questi elementi xml o bambino elemento con attributo.

Penso che nei casi più semplici, come nell'esempio in oggetto orientamento analogia funziona bene per capire che è l'elemento che è attributo di un elemento.

Solo un paio di correzioni per alcune cattive informazioni:

@Giovanni Ballinger:Attributies può contenere tutti i dati di carattere.< > & "' bisogno di essere sfuggito a <>&"e ', rispettivamente.Se si utilizza una libreria XML, che si prenderà cura di questo per voi.

L'inferno, un attributo può contenere dati binari, ad esempio un'immagine, se si vuole veramente, solo la codifica base64, rendendolo dati:URL.

@feenster:Gli attributi possono contenere separati da spazi più elementi nel caso di ID o NOMI, che comprendono i numeri.Nitpicky, ma questo può finire per risparmiare spazio.

Utilizzando gli attributi possono tenere XML competitivo con JSON.Vedere Grasso Di Markup:La rifilatura del Grasso Markup Mito una caloria in un momento.

Io sono sempre sorpreso dai risultati di questi tipi di discussioni.Per me non c'è una regola molto semplice per decidere se i dati appartiene a un attributo o come contenuto e che è se i dati sono navigabile sotto-struttura.

Così, per esempio, non-marcatura testo appartiene sempre a questi attributi.Sempre.

Le liste appartenenti a sub-struttura o il contenuto.Il testo, che l'andar del tempo possono includere strutturato sub-contenuti appartengono nel contenuto.(Nella mia esperienza, non c'è relativamente poco di questo testo con markup - quando si utilizza XML per la memorizzazione di dati o di scambio.)

XML schema scritto in questo modo conciso.

Ogni volta che vedo questi casi <car><make>Ford</make><color>Red</color></car>, Penso tra me e me "gee ha fatto l'autore a pensare che non ci sarebbero stati sub-elementi entro il make elemento?" <car make="Ford" color="Red" /> è molto più leggibile, non ci sono dubbi su come spazio sarà gestito etc.

Date solo, ma gli spazi regole di gestione, credo che questo è stato il chiaro intento di XML designer.

Questo è molto chiaro in HTML in cui le differenze di attributi e la marcatura può essere visto chiaramente:

  1. Tutti i dati tra il markup
  2. Gli attributi sono utilizzati per caratterizzare questo tipo di dati (ad es.i formati)

Se vi è solo pura dati come XML, c'è meno chiara la differenza.I dati potrebbero stare tra markup o come attributi.

=> La maggior parte dei dati dovrebbe stare tra markup.

Se si desidera utilizzare gli attributi qui:Si potrebbe dividere i dati in due categorie:Dati e "meta-dati", dove i meta dati non è parte del record, se si vuole presentare, ma cose come "formato di versione", "data", etc.

<customer format="">
     <name></name>
     ...
</customer>

Si potrebbe anche dire:"L'utilizzo di attributi caratterizzano il tag, utilizzare i tag per fornire dati.

Sono d'accordo con feenster.Stare lontano da attributi, se è possibile.Elementi evoluzione friendly e più interoperabili tra servizio web toolkit.Non lo troverete mai questi toolkit serializzazione di richiesta/risposta messaggi utilizzando gli attributi.Anche questo ha un senso dal momento che i nostri messaggi siano dati (non metadati) per un servizio web toolkit.

Gli attributi possono facilmente diventare difficile da gestire nel tempo la fiducia di me.ho sempre stare lontano da loro personalmente.Gli elementi sono molto più esplicita e leggibile e utilizzabile da entrambi i parser e gli utenti.

Solo il tempo che io abbia mai usato è stato quello di definire l'estensione del file di un bene url:

<image type="gif">wank.jpg</image> ...etc etc

credo che se si sa al 100% l'attributo non devono essere ampliate, si poteva utilizzare, ma quante volte fai a sapere che.

<image>
  <url>wank.jpg</url>
  <fileType>gif</fileType>
</image>
Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top