A linguagem XML foi inventada em 1996. Mal havia surgido, e suas possibilidades de aplicação já começaram a ser mal interpretadas, sendo que para as finalidades para as quais tentaram adaptá-la, não era a melhor escolha.
Não é exagero dizer que a esmagadora maioria dos esquemas XML que vi representava um uso inadequado ou incorreto do XML. Além disso, tal uso do XML revelava uma compreensão fundamentalmente errada do que o XML é, acima de tudo.
XML é uma linguagem de marcação. Não é um formato de dados.Na maioria dos esquemas XML, essa distinção não foi claramente considerada, confundindo XML com formato de dados, o que, no fim das contas, significou um erro na escolha do XML, já que na verdade um formato de dados era exatamente o que era necessário.
Sem entrar em detalhes, o XML é mais adequado para anotar blocos de texto com estrutura e metadados. Se seu objetivo principal não é trabalhar com um bloco de texto, a escolha do XML dificilmente será justificada.
Sob essa perspectiva, há uma maneira simples de verificar o quão bem um esquema XML foi feito. Vamos pegar como exemplo um documento no esquema proposto e remover todas as tags e atributos. Se o que sobrar não fizer sentido (ou se sobrar uma linha vazia), então ou seu esquema está mal construído, ou você simplesmente não deveria ter usado XML.
A seguir, vou apresentar alguns dos exemplos mais comuns de esquemas mal construídos.
Aqui vemos um exemplo de uma tentativa infundada e estranha (embora bastante comum) de expressar um dicionário simples "chave-valor" em XML. Se removermos todas as tags e atributos, sobrarão uma linha vazia. Essencialmente, este documento representa, por mais absurdo que pareça, uma anotação semântica de uma linha vazia.
<root name="John" city="London" />Pior ainda, não estamos apenas lidando com uma anotação semântica de uma linha vazia como uma maneira extravagante de expressar um dicionário — desta vez, o 'dicionário' está diretamente codificado como atributos do elemento raiz. Como resultado, o conjunto de nomes de atributos definido no elemento torna-se indefinido e dinâmico. Além disso, fica claro que tudo o que o autor realmente queria expressar é uma simples sintaxe de 'chave-valor', mas, em vez disso, ele adotou uma decisão absolutamente estranha de aplicar XML, forçando o uso de um único elemento vazio simplesmente como um prefixo para usar a sintaxe de atributos. E esse tipo de esquema aparece com frequência para mim.
John
LondonIsso já é um pouco melhor, mas agora as chaves, por alguma razão, são metadados e os valores não. Uma visão bastante estranha sobre dicionários. Se você remover todas as tags e atributos, metade da informação se perderá.
A expressão correta de um dicionário em XML seria mais ou menos assim:
Name
John
City
LondonMas se as pessoas tomaram a estranha decisão de aplicar XML como formato de dados e depois usar isso para organizar o dicionário, elas devem entender que o que estão fazendo é inadequado e inconveniente. Além disso, projetistas frequentemente escolhem XML de forma errada para criar suas aplicações. Mas ainda mais comum é agravarem a situação com uma aplicação sem sentido do XML em uma das formas descritas acima, ignorando o fato de que o XML simplesmente não é adequado para isso.
Qual é o pior esquema XML? A propósito, o prêmio por o pior esquema XML que já vi, vai para o formato de arquivo de configuração de alocação automática de recursos para os telefones IP da Polycom. Esses arquivos exigem o download de arquivos XML a partir de solicitações TFTP, que... Enfim, 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="..." />Isso não é uma piada infeliz de alguém. E não é uma invenção minha:
- os elementos são usados simplesmente como prefixos para anexar atributos, que por si mesmos têm nomes hierárquicos.
- Se você precisar atribuir valores a várias instâncias de um determinado tipo de registro, será necessário usar nomes de atributos, que possuem índices..
- Além disso, os atributos que começam com
softkey., devem ser colocados em elementos<softkey/>, atributos que começam comfeature., devem ser colocados 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 do atributo sempre correspondesse ao nome do elemento — nada disso! Por exemplo, os atributos
up.devem ser anexados a<userpreferences/>. A ordem de anexação dos nomes dos atributos aos elementos é aleatória, praticamente totalmente.
Documentos ou dados.De vez em quando, alguém faz coisas absolutamente estranhas, tentando comparar XML e JSON, — mostrando, assim, que não entende nenhum dos dois. XML é uma linguagem de marcação de documentos. JSON, por outro lado, é um formato de dados estruturados, então compará-los entre si é como tentar comparar coisas quentes com coisas macias.
Entender isso ajudará a esclarecer o conceito de diferença entre documentos e dados.Como analogia, XML pode ser visto como um documento legível por máquina. Embora seja destinado à leitura por máquina, metaforicamente se refere a documentos, e nesse sentido é comparável a documentos em formato PDF, que muitas vezes não são legíveis por máquina.
Por exemplo, em XML a ordem dos elementos é significativa. Já em JSON, a ordem de pares "chave-valor" dentro de objetos não tem significado e não é definida. Se você deseja obter um dicionário não ordenado de pares "chave-valor", a ordem real em que os elementos aparecem neste arquivo não importa. Mas você pode formar muitos documentos diferentes a partir desses dados, pois em um documento há uma certa ordem. Metaforicamente, isso é análogo a um documento em papel, embora não tenha dimensões físicas, ao contrário de uma impressão ou de um arquivo PDF., pois há uma ordem específica no documento. Metaforicamente, isso é análogo a um documento em papel, embora não tenha dimensões físicas, ao contrário de uma impressão ou arquivo PDF.
No meu exemplo de representação correta de um dicionário em XML, a ordem dos elementos no dicionário é mostrada, ao contrário da representação em JSON. Não posso ignorar essa ordem: tal linearidade é intrínseca ao modelo de documentos e ao formato XML. Alguém ao interpretar este documento XML pode decidir ignorar a ordem, mas discutir isso não faz sentido, pois essa questão vai além da discussão do próprio formato. Além disso, se o documento for tornado visualizável em um navegador, anexando a ele uma folha de estilo em cascata, será possível ver que os elementos do dicionário seguem uma certa ordem, e de nenhuma outra forma.
Em outras palavras, o dicionário (fragmento de dados estruturados) pode ser transformado em n diversos documentos possíveis (em formato XML, PDF, em papel, etc.), onde n — o número de combinações possíveis de elementos no dicionário, e isso sem levar em conta outras variáveis possíveis.
Ao mesmo tempo, isso também implica que se você deseja transmitir apenas dados, usar um documento legível por máquina não será eficaz. Ele utiliza um modelo que, nesse caso, é desnecessário e apenas atrapalhará. Além disso, para extrair os dados originais, será necessário escrever um programa. Dificilmente faz sentido usar XML para algo que, em determinado estágio, não será formatado como um documento (digamos, por meio de CSS ou XSLT, ou ambos), pois essa é a principal (se não a única) razão para seguir o modelo de documento.
Além disso, uma vez que em XML não existe o conceito de números (ou expressões booleanas, ou outros tipos de dados), todos os números apresentados nesse formato são considerados apenas texto adicional. Para extrair dados, é necessário conhecer o esquema e sua relação com os dados correspondentes. Também é preciso saber, com base no contexto, quando um determinado elemento de texto representa um número, e este deve ser convertido em um número, e assim por diante.
Assim, o processo de extração de dados de documentos XML não difere muito do processo de reconhecimento de documentos escaneados, que contêm, por exemplo, tabelas que formam várias páginas de dados numéricos. Sim, é possível fazer isso, mas não é o caminho mais otimizado — a menos que seja um último recurso, quando não há outras opções. Uma solução mais sensata seria simplesmente encontrar uma cópia digital dos dados originais, não integrados no modelo do documento, onde os dados estão combinados com sua representação textual específica.
Isso não me surpreende, pois o XML é popular nos negócios. A razão para isso é que o formato de documentos (em papel) é claro e familiar para as empresas, que desejam continuar utilizando um modelo conhecido e compreensível. Pelo mesmo motivo, os negócios frequentemente usam documentos em PDF em vez de formatos mais amigáveis ao processamento automático - porque ainda estão atrelados ao conceito de página impressa com um tamanho físico definido. Isso se aplica mesmo a documentos que provavelmente nunca serão impressos (por exemplo, um arquivo PDF de uma documentação de registro com 8000 páginas). Sob essa perspectiva, 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 sabem como criar processos de negócios baseados em documentos impressos. Se esse é seu ponto de referência, documentos sem um tamanho físico restrito, que são legíveis por máquina - documentos XML - representam uma inovação, ao mesmo tempo que são uma analogia familiar e confortável do documento. O que não impede que continuem sendo uma maneira errada e excessivamente skeuomórfica de representar dados.
Até agora, as únicas esquemas XML que realmente considero uma aplicação correta deste formato são XHTML e DocBook.
Fonte: habr.com
