Os elementos XML devem ter pais de agrupamento?

Question

Qual convenção seria preferida e por que (inclua alguns prós e contras de um sobre o outro)?

Este:

<company>
    <employees>
        <employee />
        <employee />
        <employee />
    </employees>
    <buildings>
        <building />
        <building />
    </building>
</company>

ou isto:

<company>
    <employee />
    <employee />
    <employee />
    <building />
    <building />
</company>

Answer 1

Não há razões semânticas para ter representação explícita da coleção através de um elemento específico. No final, ambos os documentos têm o mesmo significado - eles representam uma empresa com todos os seus funcionários e edifícios.

No entanto, existem benefícios adicionais que o primeiro exemplo oferece:

• É mais legível e pode se beneficiar do esboço nos editores.
• você pode criar esquema mais rigoroso
• É mais fácil serializar para coleções fortemente digitadas
• Você pode especificar atributos no elemento de coleta que se aplicam a todos os elementos dentro

Por outro lado, o segundo exemplo também tem alguns benefícios próprios (embora eu encontre pelo menos esses dúbios):

• é menos falador/usa menos memória
• é mais fácil de processar através de ferramentas não xml

Answer 2

Geralmente, ao lidar com XML na programação, você geralmente deseja traduzi -lo para objetos que seu programa pode usar. A maioria dos serializadores XML pega elementos para representar propriedades do elemento pai.

Quando você os agrupa como no seu exemplo superior, os serializadores podem interpretar isso como uma única coleção ou propriedade de matriz. Nesse caso, você teria um Company, que tem um Employees propriedade, que é uma coleção de Employee objetos.

Se você fizer isso da segunda maneira, você acabará com um Company objeto com propriedades chamadas "Employee", "Employee2", "Employee3"Ou algo semelhante. Quando você está programando, isso não é um bom design de objeto.

Answer 3

Existem atributos ou dados que você poderia anexar Todos os funcionários em um grupo ? Eu normalmente iria para o primeiro exemplo (um elemento de agrupamento), pois lhe dá a liberdade de

1. criar vários grupos
2. Anexe dados ao grupo como um todo

É um pouco mais detalhado, mas compra muito mais flexibilidade daqui para frente.

Answer 4

Para responder sua pergunta com uma pergunta ... como os elementos de agrupamento afetam a legibilidade, tanto visual quanto programaticamente?

O método agrupado (com o <employees> e <buildings>) é mais visual.

O método não agrupado é um pouco mais conciso para uma consulta XPath, /company/employees/employee vs. /company/employee.

Portanto, pode ser 6 de uma, meia dúzia do outro.

Answer 5

Eu abordaria isso pensando em quais dados você está representando.

Em C#, vejo isso:

// Top Example:
public class Company
{
  public Employee[] employees;
  public Building[] buildings;
}

// Vs. Bottom Example:
public Things[] employeesAndBuildings;

Logicamente, edifícios e funcionários não são a mesma coisa. Como sua empresa possui vários edifícios e vários funcionários, você deve separar logicamente os dois grupos.

O segundo exemplo é mais curto e, dependendo do que está lendo o formato, o leitor pode facilmente separar os dois itens. Para legibilidade, o formato pode ficar mais ilegível quando as coisas acontecem em uma ordem diferente:

<company>
    <employee />
    <building />
    <employee />
    <building />
    <employee />
</company>

Eu iria para o primeiro formato.