Qual escolher: atributo XML ou nó secundário?

Queremos exportar alguns dados da nossa base de dados como XML. Por exemplo, um Personpode ter age, namee algumas outras propriedades.

Temos duas opções para definir o formato XML.

Escolha 1:

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

Escolha 2:

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

Então, qual é a diferença entre a definição de subnó ou atributo? E qual é o benefício de cada escolha?

Não há documentação / prática recomendada clara para isso, mas considere as alternativas, pois você tem:

Como texto do elemento:

• pode ser mais fácil exibir os dados como xhtml etc., onde o conteúdo do texto é considerado texto, em vez de marcação ou metadados.
• pode haver mais de um. Se você precisar de conteúdo filho com várias linhas de idade ou nome, os atributos não permitirão isso
• se você precisar de metadados no nível da linha, terá a opção de usar os atributos de <name>ou <age>para essa finalidade

Como atributos:

• o XML é mais compacto
• XSLT e DocTypes são mais simples de especificar
• você não precisa se preocupar com espaços em branco (preenchimento, recuo, quebras de linha) ou outros itens que podem ser introduzidos (comentários, PIs) nas áreas PCDATA (texto do elemento)
• só pode haver um! você não precisa se preocupar com o conteúdo filho que contém vários ageatributos.

Passei muito tempo trabalhando com XML e, na minha opinião, para pura comunicação de dados, os atributos devem ser usados ​​sempre que possível. Se é provável que o XML seja usado para apresentação (XSLT, xhtml etc.), pode ser melhor como conteúdo de texto (mas não necessariamente).

Princípios do design XML: Quando usar elementos versus atributos de Uche Ogbuji da IBM é provavelmente um dos melhores recursos sobre o assunto.

No cerne da decisão está que os atributos são coisas "feitas". Você não pode alterá-los ou modificá-los ou aninhá-los. Eles são independentes de ordem e distintos dentro do elemento (você não pode ter dois da mesma coisa).

Se alguma dessas restrições mudar, faça dos dados um nó filho do XML.

No seu exemplo, você tem uma pessoa que tem nome e idade. Eu tenho um nome, meio e sobrenome ... e um apelido. E algumas pessoas têm nomes de solteira, múltiplos nomes do meio ou honoríficos - como você colocaria John Ronald Reuel Tolkien nessa estrutura?

E assim temos alguém que tem dois nomes do meio que têm uma ordem para eles. Isso deve mostrar claramente que não, um atributo não é a melhor opção para isso.

_{No momento, não consigo encontrá-lo, mas no documento vinculado acima, há uma declaração de que nomes são coisas que requerem um pouco de pensamento levando a "Espero expandir o tratamento dos nomes das pessoas na marcação em um artigo futuro". Se alguém liderar, deixe um comentário ou edite-o neste local.}

Por outro lado, a idade é algo que tem uma estrutura bastante fixa (eu sugiro o aniversário em vez de um número inteiro). Como tal, representar essas informações em um formato bem conhecido e compreendido faz sentido em um atributo. Uma pessoa tem um e apenas um aniversário e não há um 'pedido' que você deseja preservar.

Uche Ogbuji identifica três princípios básicos no design adequado de um formato xml. A seguir, são citações abreviadas do documento vinculado acima.

• Princípio da informação estruturada
  Se a informação for expressa de forma estruturada, especialmente se a estrutura puder ser extensível, use elementos. Por outro lado: se as informações forem expressas como um token atômico, use atributos
• Princípio da legibilidade
  Se as informações pretendem ser lidas e entendidas por uma pessoa, use elementos. Se a informação for mais facilmente entendida e digerida por uma máquina, use atributos.
• Princípio da ligação do elemento / atributo
  Use um elemento se precisar que seu valor seja modificado por outro atributo

E assim, os nomes devem ser elementos - são dados estruturados que não são um token atômico, são mais prováveis ​​de serem lidos por um ser humano do que por um computador e podem ser modificados por outro atributo no próprio nome.

As datas devem ser atributos - são dados que são um token atômico, são mais prováveis ​​de serem lidos por um computador do que por um ser humano (e depois transformados no formato preferido do ser humano, se necessário ) e, por último, é improvável que sejam modificados por outros atributos neles.

Outra consideração além das de Rolfl é o número de campos.
Mais do que um pequeno número de atributos se torna uma bagunça e difícil de ler (supondo que você queira que seu xml seja legível por humanos, mas como programador, você desejará fazer isso para testar pelo menos).

Além disso, se você espera que a estrutura de dados de um dos campos mude ao longo do tempo, não a torne um atributo.
Por exemplo, seu campo de nome. Talvez no futuro isso se torne

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

Se você espera que algo assim aconteça, torná-lo um atributo significaria mais código de refatoração posteriormente.

Para a tag Pessoas, é normal ter mais tags de Pessoa, faz sentido, uma lista de Pessoas tem algumas entidades, não atributos.

A história é diferente para Person e seus componentes. Uma Pessoa não contém um nome, o nome é um atributo da Pessoa, portanto, eu usaria os atributos em vez de novas tags. As tags são úteis quando você tem itens repetitivos, como endereços, não pode fazê-lo com atributos.

Se pensarmos no contexto HTML, você não tem uma entrada com uma tag de nome com um valor, não é?