Se XML é tão ruim ... por que tantas pessoas o usam? [fechadas]

Entendo o objetivo do XML, mas sempre ouço as pessoas reclamarem sobre o quão ruim é? Eu realmente não entendo o que há de tão ruim nisso? Normalmente, ouço os termos "inchado" e "lento" sendo lançados.

Mas acho que como programadores, para que você o usa principalmente? E você realmente considera isso "ruim" .... porque, se for, muita gente o usa para transportar dados ...

O XML é ótimo para o que foi projetado para ser - um protocolo de transferência de dados legível por humanos, neutro em plataforma, com alguns recursos para impor a validação de dados em níveis baixos. Duvido que qualquer pessoa que use Xml dessa maneira tenha uma queixa real. É o formato de fio mais sucinto? Não. Mas existem opções piores. É tão rápido quanto ler seu formato binário personalizado? Não. Mas seus parceiros de negócios podem lê-lo em qualquer pilha que estiverem usando.

O problema, no entanto, é que os seres humanos - especialmente a raça conhecida como arquitetos corporativos - são maus e pegam coisas boas e as tornam ruins. No caso do Xml, a parte inicial deste século viu o Xml como o martelo universal para todos os problemas de TI. Polvilhe um pouco do design do comitê e você acabará com algumas monstruosidades horríveis, como SOAP e oXML . Nenhum dos quais deve ser desejado para os inimigos, esqueça amigos ou colegas.

XML é apenas uma ferramenta que vem em muitos sabores e usos. XML se destaca em algumas coisas e suga em outras. Acho que um dos problemas é que as pessoas viram XML "corporativo" desnecessariamente complexo com espaços para nome e porcaria espalhados (SOAP, alguém?). O truque para projetar formatos XML para humanos é adicionar significado real aos dados sem torná-los impressionantes de ler.

Uma das coisas com as quais as pessoas questionam é que o XML às vezes engasga com algum caractere ou com um colchete ausente. Há, no entanto, tanto uma vantagem quanto uma desvantagem. O lado positivo é que você não tem ambiguidade, como no HTML, onde diferentes casos de sintaxe semi-inválida podem ser interpretados de maneira diferente.

A desvantagem é que é um pouco mais difícil de criar e mais difícil de aprender. Concordo que há um argumento a ser argumentado de que a Web não teria se tornado tão grande se o HTML fosse tão rigoroso quanto o XML, mas eu também argumentaria que ficaríamos felizes se isso acontecesse hoje. :)

Além disso, não o utilize para tudo, apenas porque você pode ter o bom senso e julgamento para aplicá-lo adequadamente. Se tudo o que você tem é XML, você tende a ser sempre uma transformação XSLT longe do que deseja. :)

Eu argumentaria que o formato realmente importa quando os humanos precisam interagir com ele. Se você está escrevendo algum programa que serializa alguma coisa e a envia para algum lugar onde deve ser consumido por outro programa, quem se importa com a aparência, desde que seja o mais eficiente possível? Use um formato binário ou coelhos e unicórnios para todos os cuidados.

Profissionais de XML

• Abrange muitos casos extremos que YAML e JSON não
• Existem excelentes ferramentas para analisar e validar XML em uma variedade de plataformas e linguagens diferentes
• XML pode facilmente e poderosamente ser transformado em outro formato (através de coisas como XSLT)
• Documentos XML razoáveis ​​são simples para humanos lerem e editarem; não me diga que JSON é mais fácil, não é :)
• O XML é auto-descritivo até certo ponto, ou seja, contém diretamente informações sobre sua estrutura e significado (em contraste com a maioria dos formatos binários)
• Lida com codificação
• Espaço em branco independente, o que facilita o uso entre plataformas
• Quebra se não estiver bem formado (garante que os dados estejam estruturalmente corretos)
• Não é SGML

Contras

• Verbose
• Não é tão rápido para analisar como binário
• Quebra se não estiver bem formado (trava seu aplicativo)

Bons usos

• Arquivos de configuração
• Formatos de intercâmbio de dados
• Formatos de arquivo resilientes da versão
• Armazenando documentos em bancos de dados

Usos não tão bons

• Formatos de transferência de dados
• Serializando objetos
• Armazenando dados relacionais em bancos de dados
• Formato de arquivo para cenários de E / S de alto desempenho

Jeff Atwood tem um ótimo post no XML: The Angle Bracket Tax sobre isso, se você quiser uma fonte falando sobre isso.

Os usos mais comuns que tenho para isso são:

• Serviços conversando entre si. Por exemplo, um site que usa um sistema de gerenciamento de conteúdo precisa enviar alguns dados para um sistema de gerenciamento de relacionamento com o cliente e isso é feito com XML.

• Armazenamento de configuração. Web.config e app.config são exemplos comuns, mas os scripts nAnt também podem usar algum XML para eles.

Eu não acho que é o ideal, mas isso por si só não faz mal a minha mente.

Duas razões:

1. Existem muitos programadores ruins por aí. O XML pode ser ruim, mas também é simples (pelo menos na superfície) e facilita muito a criação de software ruim. Tipo como VB.
2. Muitas pessoas que tomam essas decisões não são programadores, mas os tipos de negócios que ouviram apenas que "todo mundo está usando XML" e decidem que desejam que seu produto use XML também.

Normalmente, ouço os termos "inchado" e "lento" sendo lançados.

Não é a sintaxe mais compacta, mas é claramente a mais expressiva. Humano legível? depende de como você cria seu idioma. A maioria das pessoas não cria uma linguagem para XML, apenas serializa objetos como XML.

… Por que tantas pessoas o usam?

É onipresente. Você pode consultar um banco de dados XML com XQuery, transformar os resultados com XSLT como XHTML ou Atom, obter Atom ou outro formato XML de outros serviços da Web, obter XML de usuários usando XForms, validar com XMLSchema, Relax NG ou Schematron, processá-lo com XProc, salve-o novamente no banco de dados com o XQuery Update. Todas essas ferramentas entendem XML, portanto, não há necessidade de mapeamento entre diferentes representações.

XML não é uma tecnologia de serialização, é um conjunto de informações de uso geral.

Aqui, nós o usamos para troca de dados entre diferentes sistemas feitos por diferentes fornecedores com diferentes representações internas. Criamos um sistema de transformação / troca de XML para transferir os dados para frente e para trás. Funciona bem para isso.

XML não é inerentemente ruim, mas reconheço que projetar uma solução "boa" usando XML não é trivial.

"A essência do XML é esta: o problema que ele resolve não é difícil e não resolve bem o problema." - Phil Wadler, POPL 2003

Minha opinião pessoal é que, desde que você não se importe com validação, esquemas, XSLTs e outras coisas feias e mantenha o tamanho dos arquivos pequeno (caso contrário, a análise se torna lenta), você poderá encontrar bons usos do XML (um exemplo é para configurar seu aplicativo em vez de usar arquivos INI).

Na minha experiência, as pessoas se queixam principalmente da maneira como é usada, não da própria tecnologia.

Os bits inchados e lentos dos quais as pessoas reclamam geralmente são as bibliotecas / métodos que são usados ​​para buscar informações.

Eu o uso para armazenar pequenas quantidades de informações estruturadas que desejo armazenar em disco (sem um banco de dados ou serialização binária) ou passar para outro aplicativo (que também descreve essencialmente o SOAP).

É bom porque:

É uma "interface" padrão que vários sistemas heterogêneos podem usar para se comunicar. E é legível para "humano" (tipo, tente olhar para 5 MB de XML)

É ruim porque:

Seu tamanho maior e inchado = mais largura de banda = mais $$

Há outras razões, todo mundo tem uma queixa diferente ...

Como em qualquer outra tecnologia: existem muitas ferramentas e bibliotecas disponíveis.

Eu não gosto de XML, especialmente porque é descolado, quando as pessoas dizem que é legível por humanos, elas brincam, eu acho, ou nunca realmente leram um xml quando alguém tentou incorporar xml em um atributo ... as entidades xml o tornam realmente ilegível. Além disso, é incrível quanto espaço é desperdiçado por causa da tag final redundante e a capacidade de misturar texto e dados gratuitos ...

Mas:

• É possível especificar XML (xsd) e estão disponíveis ferramentas que verificam a conformidade dos dados XML
• muitas ferramentas (editores de texto e similares) suportam XML
• muitas bibliotecas (em todas as linguagens de programação) suportam XML

Ele também tem a vantagem de precedência, na maioria das vezes. Quando você já estiver fornecendo serviços da Web em Xml, e um solicitar um novo serviço ... provavelmente será feito em Xml, porque é isso que você sabe.

XML é uma má escolha para arquivos que devem ser mantidos por humanos. Não há separação visual entre a marcação e o conteúdo, dificultando a leitura. É entediante escrever corretamente sem um editor para fins especiais. Qualquer erro em um documento XML é fatal; um documento XML não pode ser parcialmente processado. Quando um arquivo XML é inválido, a mensagem de erro resultante geralmente é inútil.

Para qualquer arquivo que deve ser mantido por um ser humano, eu preferiria usar qualquer código JSON, YAML ou fonte em alguma linguagem interpretada (Python, Ruby, Groovy etc.). Descobrimos que uma ótima maneira de criar configuração XML para código legado é usar o Groovy MarkupBuilder. Outra boa opção é criar uma linguagem específica de domínio; isso é bastante fácil com Ruby, Groovy e muitos outros idiomas.

A análise é relativamente fácil, ao mesmo tempo em que é legível por humanos.

E alguns analisadores legais (por exemplo, Xerces {c ++}) estão prontamente disponíveis.