Atributo XML vs elemento XML

No trabalho, somos solicitados a criar arquivos XML para passar dados para outro aplicativo offline que criará um segundo arquivo XML para retornar, a fim de atualizar alguns de nossos dados. Durante o processo, discutimos com a equipe do outro aplicativo sobre a estrutura do arquivo XML.

A amostra que eu criei é essencialmente algo como:

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

A outra equipe disse que esse não era o padrão do setor e que os atributos deveriam ser usados ​​apenas para metadados. Eles sugeriram:

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

A razão pela qual sugeri a primeira é que o tamanho do arquivo criado é muito menor. Haverá aproximadamente 80000 itens que estarão no arquivo durante a transferência. Na realidade, a sugestão deles é três vezes maior do que a sugerida. Procurei o misterioso "Padrão da Indústria" mencionado, mas o mais próximo que pude encontrar foi que os atributos XML deveriam ser usados ​​apenas para metadados, mas disse que o debate era sobre o que realmente eram metadados.

Após a longa explicação (desculpe), como você determina o que são metadados e, ao projetar a estrutura de um documento XML, como você deve decidir quando usar um atributo ou elemento?

Eu uso esta regra de ouro:

1. Um atributo é algo independente, ou seja, uma cor, um ID, um nome.
2. Um elemento é algo que possui ou poderia ter atributos próprios ou conter outros elementos.

Então a sua está perto. Eu teria feito algo como:

EDIT : Atualizado o exemplo original com base nos comentários abaixo.

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

Alguns dos problemas com atributos são:

• atributos não podem conter vários valores (os elementos filhos podem)
• atributos não são facilmente expansíveis (para alterações futuras)
• atributos não podem descrever estruturas (os elementos filhos podem)
• atributos são mais difíceis de manipular pelo código do programa
• valores de atributo não são fáceis de testar em relação a uma DTD

Se você usar atributos como contêineres para dados, terá documentos difíceis de ler e manter. Tente usar elementos para descrever dados. Use atributos apenas para fornecer informações que não são relevantes para os dados.

Não termine assim (não é assim que o XML deve ser usado):

<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" significa "eXtensible Markup Language". Uma linguagem de marcação implica que os dados são texto, marcados com metadados sobre estrutura ou formatação.

XHTML é um exemplo de XML usado da maneira que foi planejado:

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

Aqui, a distinção entre elementos e atributos é clara. Os elementos de texto são exibidos no navegador e os atributos são instruções sobre como exibi-los (embora existam algumas tags que não funcionam dessa maneira).

A confusão surge quando o XML é usado não como uma linguagem de marcação, mas como uma linguagem de serialização de dados , na qual a distinção entre "dados" e "metadados" é mais vaga. Portanto, a escolha entre elementos e atributos é mais ou menos arbitrária, exceto por coisas que não podem ser representadas com atributos (veja a resposta do feenster).

Elemento XML x atributo XML

XML tem tudo a ver com acordo. Primeiro, adie para qualquer esquema XML existente ou convenções estabelecidas em sua comunidade ou setor.

Se você estiver realmente em uma situação para definir seu esquema desde o início, aqui estão algumas considerações gerais que devem informar a decisão do elemento versus atributo :

<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>

Pode depender do seu uso. O XML usado para representar dados estruturados gerados a partir de um banco de dados pode funcionar bem, com os valores de campo sendo colocados como atributos.

No entanto, o XML usado como transporte de mensagens geralmente seria melhor usando mais elementos.

Por exemplo, digamos que tivemos esse XML como proposto na resposta: -

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

Agora queremos enviar o elemento ITEM para um dispositivo para imprimir o código de barras, no entanto, há uma escolha de tipos de codificação. Como representamos o tipo de codificação necessário? De repente, percebemos, um tanto tardiamente, que o código de barras não era um único valor automic, mas pode ser qualificado com a codificação necessária quando impressa.

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

A questão é que, a menos que você construa algum tipo de XSD ou DTD junto com um espaço para nome para fixar a estrutura em pedra, é melhor você deixar as opções em aberto.

O XML IMO é mais útil quando pode ser flexionado sem quebrar o código existente usando-o.

Eu uso as seguintes diretrizes no meu design de esquema com relação a atributos x elementos:

• Use elementos para texto de execução longa (geralmente aqueles de tipos string ou normalizedString)
• Não use um atributo se houver um agrupamento de dois valores (por exemplo, eventStartDate e eventEndDate) para um elemento. No exemplo anterior, deve haver um novo elemento para "evento" que pode conter os atributos startDate e endDate.
• Data comercial, Data e hora e números (por exemplo, contagens, valor e taxa) devem ser elementos.
• Elementos de horário não comercial, como a última atualização, expira em, devem ser atributos.
• Números não comerciais, como códigos de hash e índices, devem ser atributos. * Use elementos se o tipo for complexo.
• Use atributos se o valor for um tipo simples e não se repetir.
• xml: id e xml: lang devem ser atributos referentes ao esquema XML
• Prefira atributos quando tecnicamente possível.

A preferência por atributos é que ela fornece o seguinte:

• exclusivo (o atributo não pode aparecer várias vezes)
• ordem não importa
• as propriedades acima são herdáveis ​​(isso é algo que o modelo de conteúdo "all" não suporta na linguagem de esquema atual)
• O bônus é que eles são menos detalhados e usam menos largura de banda, mas isso não é realmente um motivo para preferir atributos a elementos.

Eu adicionei quando tecnicamente possível, porque há momentos em que o uso de atributos não é possível. Por exemplo, opções de conjunto de atributos. Por exemplo, o uso (startDate e endDate) xor (startTS e endTS) não é possível com a linguagem de esquema atual

Se o esquema XML começar a permitir que o modelo de conteúdo "todo" seja restrito ou estendido, provavelmente eu o descartarei

Em caso de dúvida, KISS - por que misturar atributos e elementos quando você não tem um motivo claro para usar atributos. Se você decidir posteriormente definir um XSD, isso também será mais limpo. Então, se você decidir posteriormente gerar uma estrutura de classe a partir do seu XSD, isso também será mais simples.

Não existe uma resposta universal para essa pergunta (eu estava fortemente envolvido na criação da especificação do W3C). O XML pode ser usado para muitos propósitos - documentos como texto, dados e código declarativo são três dos mais comuns. Eu também o uso muito como modelo de dados. Existem aspectos dessas aplicações em que os atributos são mais comuns e outros em que os elementos filhos são mais naturais. Também existem recursos de várias ferramentas que facilitam ou dificultam o uso delas.

XHTML é uma área em que os atributos têm um uso natural (por exemplo, em class = 'foo'). Os atributos não têm ordem e isso pode facilitar o desenvolvimento de ferramentas para algumas pessoas. Os atributos OTOH são mais difíceis de digitar sem um esquema. Também acho que atributos com espaço para nome (foo: bar = "zork") geralmente são mais difíceis de gerenciar em vários conjuntos de ferramentas. Mas dê uma olhada em algumas das línguas do W3C para ver a mistura que é comum. SVG, XSLT, XSD, MathML são alguns exemplos de linguagens conhecidas e todos possuem um rico suprimento de atributos e elementos. Alguns idiomas até permitem mais do que uma maneira de fazê-lo, por exemplo

<foo title="bar"/>;

ou

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

Observe que estes NÃO são equivalentes sintaticamente e requerem suporte explícito nas ferramentas de processamento)

Meu conselho seria dar uma olhada na prática comum na área mais próxima do seu aplicativo e também considerar quais conjuntos de ferramentas você pode aplicar.

Por fim, certifique-se de diferenciar os espaços para nome dos atributos. Alguns sistemas XML (por exemplo, Linq) representam espaços para nome como atributos na API. OMI é feio e potencialmente confuso.

Outros abordaram como diferenciar atributos de elementos, mas de uma perspectiva mais geral, colocando tudo em atributos porque diminui o XML resultante.

O XML não foi projetado para ser compacto, mas para ser portátil e legível por humanos. Se você quiser diminuir o tamanho dos dados em trânsito, use outra coisa (como os buffers de protocolo do Google ).

a pergunta de um milhão de dólares!

primeiro, não se preocupe muito com o desempenho agora. você ficará surpreso com a rapidez com que um analisador xml otimizado rasgará seu xml. mais importante, qual é o seu design para o futuro: à medida que o XML evolui, como você manterá o acoplamento e a interoperabilidade frouxos?

mais concretamente, você pode tornar o modelo de conteúdo de um elemento mais complexo, mas é mais difícil estender um atributo.

Ambos os métodos para armazenar propriedades do objeto são perfeitamente válidos. Você deve se afastar de considerações pragmáticas. Tente responder a seguinte pergunta:

1. Qual representação leva a uma análise de dados mais rápida \ geração?

2. Qual representação leva a uma transferência de dados mais rápida?

3. A legibilidade importa?

   ...

Use elementos para dados e atributos para metadados (dados sobre os dados do elemento).

Se um elemento estiver aparecendo como predicado em suas seqüências de seleção, você tem um bom sinal de que deve ser um atributo. Da mesma forma, se um atributo nunca for usado como predicado, talvez não seja um metadado útil.

Lembre-se de que o XML deve ser legível por máquina e não legível por humanos e, para documentos grandes, o XML compacta muito bem.

É discutível de qualquer maneira, mas seus colegas estão certos no sentido de que o XML deve ser usado para "marcação" ou metadados em torno dos dados reais. Por sua parte, você está certo de que às vezes é difícil decidir onde está a linha entre metadados e dados ao modelar seu domínio em XML. Na prática, o que faço é fingir que qualquer coisa na marcação está oculta e apenas os dados fora da marcação são legíveis. O documento faz algum sentido dessa maneira?

XML é notoriamente volumoso. Para transporte e armazenamento, a compactação é altamente recomendada se você puder pagar o poder de processamento. O XML é compactado bem, às vezes fenomenalmente bom, devido à sua repetitividade. Eu tive arquivos grandes compactados para menos de 5% do tamanho original.

Outro ponto para reforçar sua posição é que, enquanto a outra equipe está discutindo sobre estilo (na medida em que a maioria das ferramentas XML processa um documento com todos os atributos tão facilmente quanto um documento com todos os # PCDATA), você está discutindo aspectos práticos. Embora o estilo não possa ser totalmente ignorado, os méritos técnicos devem ter mais peso.

É em grande parte uma questão de preferência. Uso Elementos para agrupar e atributos para dados sempre que possível, pois vejo isso como mais compacto que a alternativa.

Por exemplo, eu prefiro .....

<?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>

...Ao invés de....

<?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>

No entanto, se eu tiver dados que não representem facilmente dentro de, digamos, 20 a 30 caracteres ou contenham muitas aspas ou outros caracteres que precisam ser escapados, eu diria que é hora de quebrar os elementos ... possivelmente com blocos CData.

<?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>

Que tal tirar proveito da nossa intuição de orientação a objetos conquistada com muito esforço? Normalmente, acho que é fácil pensar qual é um objeto e qual é um atributo do objeto ou a qual objeto ele está se referindo.

O que intuitivamente faz sentido, como objetos deve caber como elementos. Seus atributos (ou propriedades) seriam atributos para esses elementos em xml ou elemento filho com atributo

Penso que em casos mais simples, como no exemplo da analogia com orientação a objetos, funciona bem para descobrir qual é o elemento e qual é o atributo de um elemento.

Apenas algumas correções para algumas informações ruins:

@ John Ballinger: os atributos podem conter qualquer dado de caractere. <> "" precisa ser escapado para "" e ", respectivamente. Se você usar uma biblioteca XML, ela cuidará disso para você.

Inferno, um atributo pode conter dados binários, como uma imagem, se você realmente quiser, apenas codificando-base64 e transformando-o em data: URL.

@feenster: os atributos podem conter vários itens separados por espaço, no caso de IDS ou NAMES, o que incluiria números. Nitpicky, mas isso pode acabar economizando espaço.

O uso de atributos pode manter o XML competitivo com o JSON. Consulte Marcação de gordura: aparando a marcação de gordura Mito uma caloria de cada vez .

Sempre fico surpreso com os resultados desse tipo de discussão. Para mim, existe uma regra muito simples para decidir se os dados pertencem a um atributo ou como conteúdo e se é que os dados têm subestrutura estruturável.

Assim, por exemplo, o texto sem marcação sempre pertence aos atributos. Sempre.

As listas pertencem à subestrutura ou ao conteúdo. O texto que pode, com o tempo, incluir sub-conteúdo estruturado incorporado pertence ao conteúdo. (Na minha experiência, há relativamente pouco disso - texto com marcação - ao usar XML para armazenamento ou troca de dados.)

O esquema XML escrito dessa maneira é conciso.

Sempre que vejo casos como esse <car><make>Ford</make><color>Red</color></car>, penso comigo mesmo "caramba, o autor achou que haveria subelementos no elemento make?" <car make="Ford" color="Red" />é significativamente mais legível, não há dúvidas sobre como o espaço em branco seria tratado etc.

Dadas apenas as regras de manipulação de espaço em branco, acredito que essa foi a intenção clara dos designers de XML.

Isso é muito claro no HTML, onde as diferenças de atributos e marcação podem ser vistas claramente:

1. Todos os dados estão entre a marcação
2. Atributos são usados ​​para caracterizar esses dados (por exemplo, formatos)

Se você apenas possui dados puros como XML, há uma diferença menos clara. Os dados podem ficar entre a marcação ou como atributos.

=> A maioria dos dados deve ficar entre as marcações.

Se você quiser usar atributos aqui: você pode dividir os dados em duas categorias: Dados e "metadados", nos quais os metadados não fazem parte do registro, você deseja apresentar, mas coisas como "versão do formato", "data da criação" , etc.

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

Pode-se também dizer: "Use atributos para caracterizar a tag, use tags para fornecer dados em si".

Eu concordo com o feenster. Fique longe de atributos, se puder. Os elementos são favoráveis ​​à evolução e mais interoperáveis ​​entre os kits de ferramentas de serviço da web. Você nunca encontraria esses kits de ferramentas serializando suas mensagens de solicitação / resposta usando atributos. Isso também faz sentido, pois nossas mensagens são dados (não metadados) para um kit de ferramentas de serviço da web.

Atributos podem facilmente se tornar difíceis de gerenciar ao longo do tempo, confie em mim. Eu sempre fico longe deles pessoalmente. Os elementos são muito mais explícitos e legíveis / utilizáveis ​​por analisadores e usuários.

A única vez que os usei foi definir a extensão do arquivo de um URL de ativo:

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

Eu acho que se você souber 100%, o atributo não precisará ser expandido, você poderá usá-los, mas quantas vezes você sabe disso.

<image>
  <url>wank.jpg</url>
  <fileType>gif</fileType>
</image>