XML quase sempre é mal utilizado

A linguagem XML foi inventada em 1996. Mal apareceu, as possibilidades da sua aplicação já começaram a ser mal compreendidas e, para os fins a que se tentava adaptá-lo, não era a melhor escolha.

Não é exagero dizer que a grande maioria dos esquemas XML que vi eram usos inadequados ou incorretos de XML. Além disso, esse uso do XML demonstrou um mal-entendido fundamental sobre o que era o XML.

XML é uma linguagem de marcação. Este não é um formato de dados. A maioria dos esquemas XML ignorou explicitamente esta distinção, confundindo XML com um formato de dados, o que em última análise resulta num erro na escolha de XML porque é o formato de dados que é realmente necessário.

Sem entrar em muitos detalhes, o XML é mais adequado para anotar blocos de texto com estrutura e metadados. Se o seu objetivo principal não é trabalhar com um bloco de texto, é improvável que a escolha de XML seja justificada.

Deste ponto de vista, existe uma maneira simples de verificar o quão bem o esquema XML é feito. Vamos pegar como exemplo um documento no esquema pretendido e remover todas as tags e atributos dele. Se o que resta não faz sentido (ou se ainda resta uma linha em branco), então seu esquema não foi construído corretamente ou você simplesmente não deveria ter usado XML.

Abaixo darei alguns dos exemplos mais comuns de circuitos construídos incorretamente.

<roоt>
  <item name="name" value="John" />
  <item name="city" value="London" />
</roоt>

Aqui vemos um exemplo de uma tentativa infundada e estranha (embora muito comum) de expressar um simples dicionário de valores-chave em XML. Se você remover todas as tags e atributos, ficará com uma linha vazia. Essencialmente, este documento é, por mais absurdo que possa parecer, uma anotação semântica de uma linha vazia.

<root name="John" city="London" />

Para piorar a situação, não temos aqui apenas uma anotação semântica de uma string vazia como uma forma extravagante de expressar um dicionário - desta vez o "dicionário" é codificado diretamente como atributos do elemento raiz. Isso torna o conjunto fornecido de nomes de atributos em um elemento indefinido e dinâmico. Além disso, mostra que tudo o que o autor realmente queria expressar era uma simples sintaxe de valor-chave, mas em vez disso ele tomou a decisão absolutamente bizarra de aplicar XML, forçando o uso de um único elemento vazio simplesmente como um prefixo para usar a sintaxe de atributos. E encontro esses esquemas com frequência.

<roоt>
  <item key="name">John</item>
  <item key="city">London</item>
</roоt>

Isso é algo melhor, mas agora, por algum motivo, as chaves são metadados e os valores não. Uma visão muito estranha dos dicionários. Se você remover todas as tags e atributos, metade das informações será perdida.

Uma expressão de dicionário correta em XML seria mais ou menos assim:

<roоt>
  <item>
    <key>Name</key>
    <value>John</value>
  </item>
  <item>
    <key>City</key>
    <value>London</value>
  </item>
</roоt>

Mas se as pessoas tomaram a estranha decisão de usar XML como formato de dados e depois usá-lo para organizar um vocabulário, então elas deveriam entender que o que estão fazendo é inapropriado e não conveniente. Também é comum que designers escolham erroneamente XML para criar seus aplicativos. Mas ainda mais frequentemente, eles pioram a situação ao usar XML sem sentido em uma das formas descritas acima, ignorando o fato de que XML simplesmente não é adequado para isso.

Pior esquema XML? Aliás, o prêmio para o pior esquema XML que já vi, Obtém o formato do arquivo de configuração de provisionamento automático para telefones de telefonia IP Polycom. Esses arquivos requerem o download de arquivos de solicitação XML via TFTP, que... Em geral, aqui está um trecho de um desses arquivos:

<softkey
        softkey.feature.directories="0"
        softkey.feature.buddies="0"
        softkey.feature.forward="0"
        softkey.feature.meetnow="0"
        softkey.feature.redial="1"
        softkey.feature.search="1"

        softkey.1.enable="1"
        softkey.1.use.idle="1"
        softkey.1.label="Foo"
        softkey.1.insert="1"
        softkey.1.action="..."

        softkey.2.enable="1"
        softkey.2.use.idle="1"
        softkey.2.label="Bar"
        softkey.2.insert="2"
        softkey.2.action="..." />

Esta não é uma piada de mau gosto de alguém. E esta não é minha invenção:

• os elementos são simplesmente usados ​​como um prefixo para anexar atributos, que possuem nomes hierárquicos.
• Se quiser atribuir valores a múltiplas instâncias de um determinado tipo de registro, você deverá usar nomes de atributos para fazer isso. que possuem índices.
• Além disso, atributos começando com softkey., deve ser colocado em elementos <softkey/>, atributos começando com feature., deve ser colocado em elementos <feature/> etc., apesar de parecer completamente desnecessário e à primeira vista sem sentido.
• E finalmente, se você esperava que o primeiro componente do nome de um atributo fosse sempre igual ao nome do elemento - nada disso! Por exemplo, atributos up. deve ser anexado <userpreferences/>. A ordem de anexação de nomes de atributos aos elementos é arbitrária, quase completamente.

Documentos ou dados. De vez em quando, alguém faz algo completamente estranho ao tentar comparar XML e JSON – e assim mostrar que também não entende. XML é uma linguagem de marcação de documentos. JSON é um formato de dados estruturado, portanto, compará-los entre si é como tentar comparar quente com suave.

O conceito da diferença entre documentos e dados. Como análogo do XML, podemos considerar condicionalmente um documento legível por máquina. Embora se destine a ser legível por máquina, refere-se metaforicamente a documentos e, deste ponto de vista, é na verdade comparável a documentos PDF, que na maioria das vezes não são legíveis por máquina.

Por exemplo, em XML a ordem dos elementos é importante. Mas em JSON, a ordem dos pares de valores-chave nos objetos não tem sentido e é indefinida. Se você deseja obter um dicionário não ordenado de pares de valores-chave, a ordem real em que os elementos aparecem nesse arquivo não importa. Mas você pode formar muitos tipos diferentes de dados a partir desses dados. de documentos, porque há uma certa ordem no documento. Metaforicamente, é análogo a um documento em papel, embora não possua dimensões físicas, ao contrário de uma impressão ou arquivo PDF.

Meu exemplo de representação de dicionário XML adequada mostra a ordem dos elementos no dicionário, em oposição à representação JSON. Não posso ignorar esta ordem: esta linearidade é inerente ao modelo do documento e ao formato XML. Alguns podem optar por ignorar a ordem ao interpretar este documento XML, mas não faz sentido discutir sobre isso, uma vez que a questão está além do escopo de uma discussão sobre o formato em si. Além disso, se você tornar o documento visível no navegador anexando uma folha de estilo em cascata a ele, verá que os elementos do dicionário aparecem em uma determinada ordem e em nenhuma outra.

Em outras palavras, um dicionário (um dado estruturado) pode ser convertido em n vários documentos possíveis (em XML, PDF, papel, etc.), onde n - o número de combinações possíveis de elementos no dicionário, e ainda não levamos em consideração outras variáveis ​​​​possíveis.

No entanto, também se segue que se você deseja transferir apenas dados, usar um documento legível por máquina para isso não será eficaz. Utiliza um modelo, que neste caso é supérfluo, só vai atrapalhar. Além disso, para extrair os dados originais, você precisará escrever um programa. Não faz sentido usar XML para algo que não será formatado como um documento em algum momento (digamos, usando CSS ou XSLT, ou ambos), já que essa é a principal (se não a única) razão para aderir. ao modelo do documento.

Além disso, como o XML não tem conceito de números (ou expressões booleanas, ou outros tipos de dados), todos os números representados neste formato são considerados apenas texto adicional. Para extrair dados, o esquema e seu relacionamento com os dados correspondentes expressos devem ser conhecidos. Você também precisa saber quando, com base no contexto, um determinado elemento de texto representa um número e deve ser convertido em um número, etc.

Assim, o processo de extração de dados de documentos XML não é tão diferente do processo de reconhecimento de documentos digitalizados contendo, por exemplo, tabelas formando muitas páginas de dados numéricos. Sim, é possível fazer isso em princípio, mas esta não é a maneira mais ideal, exceto como último recurso, quando não há absolutamente nenhuma outra opção. Uma solução razoável é simplesmente encontrar uma cópia digital dos dados originais que não esteja incorporada em um modelo de documento que combine os dados com sua representação textual específica.

Dito isto, não me surpreende que o XML seja popular nos negócios. A razão para isto é precisamente que o formato do documento (em papel) é compreensível e familiar para as empresas, e elas querem continuar a utilizar um modelo familiar e compreensível. Pela mesma razão, as empresas utilizam frequentemente documentos PDF em vez de formatos mais legíveis por máquinas - porque ainda estão ligados ao conceito de uma página impressa com um tamanho físico específico. Isto se aplica até mesmo a documentos que provavelmente nunca serão impressos (por exemplo, um PDF de 8000 páginas de documentação de registro). Deste ponto de vista, o uso de XML nos negócios é essencialmente uma manifestação de skeuomorfismo. As pessoas entendem a ideia metafórica de uma página impressa de tamanho limitado e entendem como criar processos de negócios baseados em documentos impressos. Se esse for o seu guia, documentos sem limitações de tamanho físico que podem ser lidos por máquinas (documentos XML) representam inovação e ao mesmo tempo são uma contrapartida de documento familiar e confortável. Isto não os impede de continuarem a ser uma forma incorreta e excessivamente skeuomórfica de apresentar dados.

Até o momento, os únicos esquemas XML que conheço e que posso realmente chamar de uso válido do formato são XHTML e DocBook.

Fonte: habr.com