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

37

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 ...

programming-practices xml
fonte
11
Sua resposta está na pergunta. As pessoas ainda o usam porque as pessoas costumavam usá-lo, e as opções são (1) reescrever todo o código que o usou antes do JSON e YAML, ou (2) sugá-lo e fazer a coisa estúpida. Muitas pessoas ainda perpetuam ciclos de violência também. Isso não prova o valor inerente da prática.
Tiro parta
5
Tente JSON para um documento real (página de manual, Knuth, Hamlet, etc). Você entenderá por que o XML é essencial. Este é um espaço em que o JSON é péssimo (vá em frente, tente). Usar qualquer um no espaço de design do outro é questionável. Os problemas do uso de XML no espaço do JSON são principalmente verbosidade e velocidade, enquanto os problemas do uso do JSON no espaço do XML tendem a envolver portabilidade (tente interoperar com um amigo que fez um livro em JSON, mas à sua maneira), integridade e problemas de interpretação que exigem muito esforço humano para corrigir. Use a ferramenta certa para o seu trabalho.
TextGeek
O XML é ruim apenas porque muitas pessoas abusam dele por coisas que não foram projetadas. Se você não precisa que seus dados sejam facilmente extensíveis (ou seja, o esquema é usado por várias partes que precisam interoperar, em vez de ser ditado centralmente por uma parte autorizada), e se seus dados não são um documento (por exemplo, se o DOM exigiria uma má abstração de seus dados), então o XML não é adequado para esses aplicativos. Porém, quando o domínio do problema se enquadra no que o XML foi projetado, nada mais corresponde ao XML. JSON, YAML etc. não são adequados para o espaço para o qual o XML realmente foi projetado.
Lie Ryan

Respostas:

90

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.

Wyatt Barnett
fonte
15
+1 - qualquer pessoa que já tenha lidado com EDI só deseja que o XML tenha sido inventado antes que essa bagunça acontecesse.
Scott Whitlock
12
+1 Corresponde quase exatamente aos meus pensamentos. Eu apenas acrescentaria que, para armazenar dados simples e simples, mesmo que sejam hierárquicos (mas não muito profundos, que não combinam bem com nada ), existem certos formatos que funcionam tão bem - principalmente JSON e YAML. Este último é impressionante em relação à legibilidade humana.
11
Parafraseando jwz: "Há um certo tipo de programador que analisará qualquer problema e dirá: 'Eu sei, vou usar XML'. Agora ele tem dois problemas. "
Adam Crossland
13
Diga-me que o oXML foi planejado como uma piada, como Brainfuck ou Whitespace ou LOLCODE.
dsimcha
9
@ Shamim Hafiz, o SOAP está definitivamente entre as piores monstosidades já criadas pela humanidade.
SK-logic
24

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
Homde
fonte
13
Duvido que "arquivos de configuração" estejam em "bons usos". Eles não são dados, são instruções.
daknøk
3
Estou com @ daknøk aqui - não posso contar os tempos em que passei muito tempo descobrindo um bug de configuração em centenas de arquivos XML de linhas longas que especificam a injeção de dependência, baseada em um pequeno erro de digitação. um atributo XML.
Gjallar
3
Se dados incorretos travam um aplicativo, são os dados que apresentam um problema?
James Snell
4
Qualquer formato de arquivo malformado / corrompido tem o potencial de travar um software danificado. Portanto, XML não é o culpado aqui ... apenas seu aplicativo. Caso contrário, boa postagem.
9788 Thomas Eding
3
Você poderia expandir em "Abrange muitos casos extremos que YAML e JSON não."?
Trevor Hickey
14

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.

JB King
fonte
11

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.
Mason Wheeler
fonte
Que pontos absurdos e totalmente inúteis. 1) XML está longe de ser ruim e não tem absolutamente nada a ver com a qualidade do software que as pessoas escrevem, independentemente de escolherem ou não, eu já vi bons programadores de VB, o que implica que, se você usa o VB, na verdade, ele escreve software ruim apenas bobo porque há uma desconexão completa entre como você escreve software e com o que você usa para escrevê-lo. 2) Ainda outra suposição falsa, a escolha de XML é ótima e a maioria das pessoas que a escolhe para melhor ou para pior é certamente programadora. XML não é uma bala de prata, mas é bom para certas coisas.
Eyal Solnik
2
@EyalSolnik: Algumas pessoas, quando apresentados com um problema, pense “Eu sei, eu vou usar XML.”<Problem:Worsening> <Problem:TimeDescription>Now</Problem:TimeDescription> <Problem:Posessive>they have</Problem:Posessive> <Problem:Quantity>many, many</Problem:Quantity> <Problem:WorseningDescription>more problems</Problem:WorseningDescription> </ProblemWorsening>
Mason Wheeler
3
Só porque as pessoas abusam de algo não significa que a tecnologia em si é ruim, você pode ver a mesma síndrome em muitos lugares.
Eyal Solnik 27/05
8

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.

Max Toro
fonte
... e nos perguntamos há anos por que, para chrissakes, o SOAP foi construído sobre XML.
JensG
6

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.

FrustratedWithFormsDesigner
fonte
5

"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).

sakisk
fonte
4

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).

Steven Evers
fonte
2

É 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 ...

Noite escura
fonte
4
@Darknight: Eu desafio o humano legível jogando entidades XML em você ... (implicância pessoal)
Matthieu M.
11
Não acho que o XML seja inerentemente inchado - mas as implementações são. Acho que o XML-RPC é particularmente notório em inchaços desnecessários.
21711 HorusKol
3
@HorusKol: <advanceAcceptanceIndicator>Y</advanceAcceptanceIndicator>A proporção de dados / marcação é tão baixa ... eu chamo isso de "inchado". JSON, por exemplo, seria apenas como meio inchado: advanceAcceptanceIndicator: "Y". Também existe o fato de que o texto entre as tags é válido; portanto, ao ler o Xml, você precisa decidir o que fazer com esse cruft \n\t\t\t, e a solução geralmente é ignorá-lo, porque você nunca estava realmente interessado nisso.
Matthieu M. 24/03
11
@HorusKol: Seria, mas eu nunca disse que era um valor booleano, apenas um caractere :) O uso do atributo aqui ( value?) Provavelmente também seria superior, porque as pessoas poderiam ser tentadas a inserir espaços em branco entre dois Tag.
Matthieu M.
11
"Seu tamanho maior e inchado = mais largura de banda = mais $$" Acho que a compressão ainda não foi inventada onde você está.
Andy
2

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.

Matthieu M.
fonte
5
XML é mais legível que dados binários ou de posição ou vírgula.
FrustratedWithFormsDesigner
Somente para um usuário ingênuo. Se eu tiver que digitalizar visualmente algumas centenas de registros procurando um que esteja faltando alguns dados, prefiro procurar algumas colunas em branco em um bloco de registros de comprimento fixo do que percorrer um pântano de elementos e atributos procurando uma tag vazia.
TMN
11
@FrustratedWithFormsDesigner: realmente depende dos dados disponíveis. O XML incorpora a natureza da informação próxima à informação adequada. Se você olhar para linguagens de programação funcionais, verá coisas como (Haskell):, data Person = Person { surname :: String, firstName :: String, age :: Int }se eu também ver Person "Doe" "John" 42que é legível e evitar muita confusão, ainda assim é mais próximo da delimitação por vírgula.
Matthieu M. 23/03
11
Ok, seu exemplo foi mais fácil de ler sem a marcação, mas podem ser feitos exemplos triviais (eu diria menos de 8 ou 9 elementos de dados) para dar suporte a todos os formulários (exceto talvez binários). Os feeds de dados do mainframe se originam como strings delimitadas por posição (e a maioria são apenas códigos numéricos), e são muito mais fáceis de ler, depurar e gerenciar após serem transformadas em XML. Como você disse, ele pode depender ...
FrustratedWithFormsDesigner
@FrustratedWithFormsDesigner: Sim, esse é exatamente o meu ponto :) Depende, mas porque existe um ecossistema tão rico para XML e porque é mais fácil manter apenas um conjunto de ferramentas / bibliotecas, as pessoas geralmente usam XML para tudo. Pessoalmente, sou a favor JSon sobre XML, mas mais uma vez, sem recuo, é confuso: p
Matthieu M.
-1

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.

Kevin Cline
fonte
8
Eu acho que você está perdendo o ponto de XML, a marcação é o conteúdo. O objetivo do XML é descrever o significado dos seus dados. Por exemplo, se você tiver um número de telefone, identificá-lo como número de telefone fixo ou número de celular adiciona o contexto que outros podem usar. Ou adicionar uma etiqueta telefônica ao redor do texto para esse assunto (pode tornar esse número possível de chamar em um telefone celular). Quanto aos seus outros pontos, eu também discordo. A criação de documentos xml geralmente é bastante direta. Mensagens de erro são sempre relacionados a wellformedness e eu vou levar edição de XML com a mão sobre JSON qualquer dia
Homde
@konrad O exemplo do seu telefone seria válido para HTML.
Florian F
"Qualquer erro em um documento XML é fatal; um documento XML não pode ser parcialmente processado." Sim, isso é muito importante para o ponto do XML.
Andy
@ Andy É muito inútil se o XML foi escrito pelo ser humano e o aplicativo diz apenas "errado!". Um editor humano precisa conhecer a linha em que o erro foi detectado.
Kevin cline
Qualquer número de ferramentas informa exatamente em que linha e com que caractere o erro é detectado. Ferramentas XML no NotePad ++, por exemplo. O .Net também informará exatamente onde o arquivo .config está errado. Se você está falando de uma API, um dos benefícios do XML é que o desenvolvedor da API também pode fornecer um XSD, que além de garantir a sintaxe XML válida também pode informar se você possui algum elemento que não pertence, se houver seja apenas um desse elemento, etc. O json manuscrito é muito mais fácil de estragar.
218 Andy Andy
-2

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.

Simon
fonte
2
Bem, é fácil, desde que os documentos sejam pequenos. Se você precisar analisar documentos muito grandes para caber razoavelmente na memória, as coisas ficarão sombrias.
TMN
Eu questionaria a parte da legibilidade humana. É preciso muito esforço para ler XML em vez de ler um JSON equivalente.
cmaster 27/03