A linguagem XML foi inventada em 1996. Ele mal apareceu antes que as possibilidades de sua aplicação já tivessem começado a ser mal compreendidas e, para os propósitos para os quais tentaram adaptá-lo, ele não era a melhor escolha.
Não seria exagero dizer que a grande maioria dos esquemas XML que eu vi são inapropriados ou abusam do XML. Além disso, esse uso do XML atestou um mal-entendido fundamental sobre o que é o XML.
XML é uma linguagem de marcação.
Este não é um formato de dados . Na maioria dos esquemas XML, essa distinção não foi explicitamente levada em consideração, confundindo XML com o formato dos dados, o que acabou por significar um erro na escolha do XML, porque, na verdade, o formato dos dados era necessário.
Sem entrar em detalhes, o XML é melhor para anotar blocos de texto com estrutura e metadados. Se sua tarefa principal não é trabalhar com um bloco de texto, é improvável que a escolha de XML seja justificada.
Desse ponto de vista, há uma maneira fácil de verificar o quão bem o esquema XML é feito. Pegue, por exemplo, o documento no esquema proposto e remova todas as tags e atributos dele. Se não houver sentido no que resta (ou se uma cadeia vazia permanecer), seu esquema não será construído corretamente ou você não deveria ter usado XML.
Abaixo darei alguns dos exemplos mais comuns de circuitos construídos incorretamente.
<rot> <item name="name" value="John" /> <item name="city" value="London" /> </rot>
Aqui vemos um exemplo de uma tentativa irracional e estranha (embora muito difundida) de expressar um dicionário simples de valor-chave em XML. Se você excluir todas as tags e atributos, uma linha vazia permanecerá. Essencialmente, este documento é, por mais absurdo que possa parecer, a anotação semântica de uma linha vazia.
<root name="John" city="London" />
Para piorar a situação, temos aqui não apenas uma anotação semântica de uma linha vazia como uma maneira extravagante de expressar um dicionário - dessa vez, o "dicionário" é diretamente codificado como atributos do elemento raiz. Por esse motivo, um determinado conjunto de nomes de atributos em um elemento se torna indefinido e dinâmico. Além disso, é claro daqui que tudo o que o autor realmente queria expressar era uma sintaxe simples de valor-chave, mas, em vez disso, tomou uma decisão absolutamente estranha de usar XML, forçando o uso de um único elemento vazio como prefixo a ser usado. sintaxe de atributo. E esses esquemas me ocorrem com muita frequência.
<rot> <item key="name">John</item> <item key="city">London</item> </rot>
Isso já é algo melhor, mas agora as chaves são metadados por algum motivo, mas os valores não são. Um olhar muito estranho nos dicionários. Se você excluir todas as tags e atributos, metade das informações serão perdidas.
A expressão correta do dicionário em XML será mais ou menos assim:
<rot> <item> <key>Name</key> <value>John</value> </item> <item> <key>City</key> <value>London</value> </item> </rot>
Mas se as pessoas tomarem a estranha decisão de usar XML como formato de dados e, em seguida, usá-lo para organizar o dicionário, deverão entender que o que estão fazendo é inapropriado e não conveniente. Ainda com frequência, os designers escolhem o XML por engano para criar seus aplicativos. Mas com mais freqüência, eles exacerbam a situação pelo uso sem sentido do XML em uma das formas descritas acima, ignorando o fato de que o XML simplesmente não é adequado para isso.
Pior esquema XML? A propósito, o prêmio pelo
pior esquema XML que eu já vi obtém o formato do arquivo de configuração de alocação automática de recursos para telefones de telefonia IP da Polycom. Esses arquivos requerem o carregamento de arquivos de solicitação XML via TFTP, o 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="..." />
Isso não é uma piada de mau gosto. E esta não é minha invenção:
- elementos são simplesmente usados como prefixo para anexar atributos, que possuem nomes hierárquicos.
- Se você deseja atribuir valores a várias instâncias de um registro de um determinado tipo, é necessário usar os nomes dos atributos nos quais existem índices .
- Além disso, atributos começando com a
softkey. , você precisa colocar nos elementos <softkey/> atributos que começam com o feature. , deve ser colocado nos <feature/> etc., apesar de parecer completamente redundante e, à primeira vista, inútil.
- E, finalmente, se você esperava que o primeiro componente do nome do atributo sempre corresponda ao nome do elemento - nada disso! Por exemplo, os atributos
up. deve ser anexado a <userpreferences/> . A ordem de anexar nomes de atributos a elementos é arbitrária e quase completamente.
Documentos ou dados . De tempos em tempos, alguém faz coisas absolutamente estranhas, tentando comparar XML e JSON - e, assim, mostrando que ele não entende um ou outro. XML é uma linguagem de marcação de documento. O JSON é um formato de dados estruturado, portanto, compará-lo entre si é como tentar comparar entre quente e suave.
Para entender isso, o conceito da diferença entre
documentos e dados ajudará. Como análogo do XML, você pode tirar arbitrariamente um documento legível por máquina. Embora ele deva ser lido por uma máquina, ele se refere metaforicamente a documentos e, desse ponto de vista, é realmente comparável a documentos em PDF, que geralmente não são legíveis por máquina.
Por exemplo, em XML, a ordem dos elementos é importante. E no JSON, a ordem dos pares de valores-chave dentro dos objetos não faz sentido e não está definida. Se você deseja obter um dicionário não ordenado de pares de valores-chave, a ordem real pela qual os itens deste arquivo seguem não importa. Mas você pode formar muitos
documentos diferentes a partir desses dados, porque o documento tem uma determinada ordem. Metaforicamente, é um análogo de um documento em papel, embora não tenha dimensões físicas, diferentemente de uma impressão ou de um arquivo PDF.
No meu exemplo da representação correta do dicionário em XML, a ordem dos elementos no dicionário é mostrada, em contraste com a representação na linguagem JSON. Não posso ignorar esta ordem: essa linearidade é inerente ao modelo de documento e formato XML. Ao interpretar este documento XML, alguém pode decidir ignorar a ordem, mas não faz sentido argumentar sobre isso, pois esse problema vai além da discussão do próprio formato. Além disso, se você tornar um documento visível em um navegador anexando uma folha de estilos em cascata, poderá ver que os elementos do dicionário seguem uma certa ordem e de nenhuma outra maneira.
Em outras palavras, um dicionário (um fragmento de dados estruturados) pode ser convertido em
n diferentes 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 conta os outros variáveis possíveis.
No entanto, também decorre disso que, se você deseja transmitir dados sozinho, o uso de um documento legível por máquina para isso não será eficaz. Ele usa um modelo, que neste caso é supérfluo, apenas interfere. Além disso, para extrair os dados de origem, será necessário escrever um programa. Dificilmente faz sentido usar XML para algo que em um certo estágio não será formatado como um documento (digamos, usando CSS ou XSLT, ou ambos), pois essa é a principal (se não a única) razão para isso. aderir ao modelo de documento.
Além disso, como XML não possui o conceito de números (ou expressões booleanas ou outros tipos de dados), todos os números representados nesse formato são considerados apenas texto adicional. Para extrair os dados, o esquema e sua relação com os dados expressos correspondentes devem ser conhecidos. Também é necessário saber quando, com base no contexto, um ou outro elemento do texto é um número e deve ser convertido em um número, etc.
Portanto, o processo de extração de dados de documentos XML não é tão diferente do processo de reconhecimento de documentos digitalizados que contêm, por exemplo, tabelas que formam muitas páginas de dados numéricos. Sim, em princípio, é possível fazer isso, mas essa não é a maneira mais ideal, a menos que em um caso extremo, quando não houver outras opções. Uma decisão inteligente seria simplesmente encontrar uma cópia digital dos dados originais que não estão incorporados no modelo de documento, na qual os dados são combinados com sua representação textual específica.
No entanto, não me surpreende que o XML seja popular nos negócios. A razão para isso é justamente porque o formato dos documentos (no papel) é compreensível e familiar para os negócios e eles desejam continuar usando o modelo familiar e compreensível. Pelo mesmo motivo, nos negócios, muitas vezes, use documentos em PDF em vez de mais conveniente para os formatos de processamento da máquina - porque eles ainda estão vinculados ao conceito de uma página impressa com um determinado tamanho físico. Isso se aplica mesmo a documentos que provavelmente nunca serão impressos (por exemplo, um arquivo PDF da documentação do registro de 8.000 páginas). Desse 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 com base em documentos impressos. Se essa é sua orientação, documentos sem tamanho físico limitado, legíveis por máquina - documentos XML - são uma inovação e, ao mesmo tempo, são um análogo familiar e confortável de um documento. O que não os impede de manter uma maneira incorreta e excessivamente ckeuomórfica de apresentar dados.
Até o momento, os únicos esquemas XML que sei que realmente posso chamar de uso adequado desse formato são XHTML e DocBook.