XML não é a resposta

Não me entenda mal, XML é uma idéia interessantíssima, pela qual sou apaixonado. Tenho dado aula de XML, escrito HTML como XML válido, publicado e consumido dados em XML, acompanhado as iniciativas de Open Data e RDF no W3C.

O problema é que, enquanto alguns mercados subutilizam XML, tornando o intercâmbio de dados muito complexo, outros exageram no uso. XML não é a panaceia da troca de dados.

Há, por exemplo, uma porção de sistemas que usam XML como arquivos de configuração. Isso torna complicado o trabalho de editar esses XML, e na maioria dos casos torna complicado o parsing disso para rodar o sistema.

Veja um breve exemplo: a busca do Twitter está disponível em três formatos, HTML, ATOM e JSON. Teste a busca a seguir nesses três formatos (veja a diferença nas URLs):

http://search.twitter.com/search?q=%40elcio (HTML)

http://search.twitter.com/search.atom?q=%40elcio (ATOM)

http://search.twitter.com/search.json?q=%40elcio (JSON)

A maneira como o Twitter publica suas buscas é inspiradoras. O formato ATOM servirá para leitores de feeds e para aqueles programadores que adoram escrever parsers XML. E para o resto do mundo, temos JSON. Veja como consumir a URL JSON e obter dados nativos no Python:

import json,urllib2
url='http://search.twitter.com/search.json?q=%40elcio'
dados=json.load(urllib2.urlopen(url))

A dica então é se perguntar se XML é necessário e, se não tiver um bom motivo para usá-lo, trabalhar com JSON, YAML ou, quem sabe, um arquivo de configuração declarando variáveis em sua própria linguagem.

Publicado por

Elcio

Elcio é sócio fundador da Visie Padrões Web. Pioneiro no uso e divulgação dos padrões do W3C no Brasil, Elcio já treinou equipes de dezenas de empresas como Globo.com, Terra, Petrobras, iG e Locaweb. Além disso, tem dirigido as equipes da Visie no desenvolvimento de projetos web para marcas como Brastemp, Itaú Unibanco, Johnson & Johnson e Rede Globo.

16 comentários em “XML não é a resposta”

  1. Pingback: XML não é a resposta 2: parsing

  2. Élcio,

    Concordo em partes com você.
    Concordo que o XML é muitas vezes utilizado sem sentido nenhum, ele é uma opção, e como qualquer opção; tem vantagens e desvantagens em determinadas situações.

    Uma coisa que é importante mencionar, é o porquê do XML ter tomado conta do mundo do jeito que tomou: DTD’s. A possibilidade do XML ter um descritor pra validar sua formação facilita muito a escrita dos mesmos em uma IDE que interprete isso (até editores de texto voltados pra DEVs têm isso). E me assusta ver que a grande maioria das pessoas (até as que usam XML) desconhecem isso.

    O mais importante é conhecer as tecnologias disponíveis e escolher a melhor. Não a melhor pra você, mas a melhor pra situação em si.

    Responder

  3. Como o Igor disse, a vantagem do XML é o ecossistema de tecnologias e ferramentas com as quais você pode trabalhar em conjunto com ele. Isso está se tornando uma realidade pra outros formatos como JSON e YAML também, mas ainda não chegam perto em volume e funcionalidade.

    Algumas bibliotecas e frameworks configuráveis por XML constroem DTDs/Schemas para validar os arquivos de configuração. Com esse DTD, tanto a aplicação quando a IDE conseguem validar se aquele conjunto de configurações é válido sem ter que sujeitar a aplicação a falhas para verificar.

    Como eu programo quase exclusivamente com PHP, há muito pouca diferença entre usar simplexml_load_file(), json_decode() ou parse_ini_file(). Os três são rápidos e simples de usar. Desses, prefiro arquivos INI que além de tudo são mais simples de ler e editar, sem preocupar-se com tags, aspas ou chaves. A sintaxe simplesmente “sai do caminho”

    Responder

  4. Sempre achei controverso escolhermos um formato de arquivo “human readable” para trafegar dados entre máquinas. Navegador não faz “parse” de JSON, quem faz “parse” de JSON é javascript ou alguma outra linguagem de programação – certo que o Firefox bolinha tem um “parser” implementado internamente pelo que me lembro.

    Meu ponto é o seguinte: se XML não é a resposta, JSON também não é: basta contar quantas vezes a string “profile_image_url” aparece no JSON feed do twitter para perceber… :]

    Pirolla.

    Responder

    1. Pirolla,

      A diferença está em como fazer esse parsing. JSON foi feito para descrever dados nativos. Qualquer estrutura em JSON pode ser traduzida automaticamente para dicionários, listas, strings, números e booleanos. Isso simplifica tudo.

      Além disso, o parsing em Javascript, para Ajax, é um assunto a parte. JSON não é um formato de dados que precise ser parsed pelo Javascript. JSON é Javascript.

      Um parser de JSON em Javascript com uma linha:

      dados=eval('['+json+']')[0]

      Sei, eval is evil, e etc. Mas esse é um caso a parte, assunto para outro artigo.

      Responder

  5. RDF é um modelo que independe da sua forma de serialização. Apesar do RDF/XML ser a serialização do RDF descrita na especificação, há outras que já são consideradas padrões “de-facto”, como Turtle [1] e Notation 3 [2]. Essas serializações são mais fáceis de ler para seres humanos ao mesmo tempo que são processáveis por máquina. Há, ainda, propostas [3] de serialização em JSON [4] para o RDF.

    Eu chegaria a dizer que o XML, apesar de suportado, não é necessário nem para a Web Semântica nem para da Dados Vinculados.

    [1] http://en.wikipedia.org/wiki/Turtle_(syntax)
    [2] http://en.wikipedia.org/wiki/Notation_3
    [3] http://www.w3.org/2009/12/rdf-ws/papers/ws02
    [4] http://n2.talis.com/wiki/RDF_JSON_Specification

    Responder

  6. A era do XML para troca de dados já era, detesto modismos e XML é um modismo tão medonho, contaminou tudo de transferência de simples dados ate configurações de sistemas, detesto mexer em tags para configurar ambientes, que é muitas vezes confuso. Pra que um ser humano precisa entender uma mensagem automática que será lida por um sistema e traduzida pelo mesmo? Por essas e outras digo que retornaremos ao binário em breve, é mais enxuto, mais rápido de processar, menor em tamanho, só tem vantagem :D.

    Responder

  7. O XML é só a ponta do iceberg. É somente mais uma tecnologia disponível para podermos escolher a qual melhor se adapta a nossa necessidade. O uso do XML se torna interessante quando utilizamos tecnologias em conjunto como o XSLT. Não conseguimos fazer nada do tipo se utilizarmos um formato tão simples (porém focking awesome) como o JSON. Todo mundo acha que o poder do XML se limite somente na montagem de um RSS mas estão enganados. Inspirados nele temos o XSLT, MathML o próprio XHTML, RDF, SVG, XSIL e SDMX.

    Concordo com o que você diz quando fala “A dica então é se perguntar se XML é necessário”. Não devemos utilizar mesmo XML para tudo. Hoje temos tecnologias muito mais práticas e que atendem a grande maioria das necessidades.

    []’s
    Igor Escobar

    Responder

  8. Concordo em partes.

    Concordo com @dgmike que as configurações não devem ser, e geralmente não são, alteradas por leigos.

    Fato que toda aplicação dispõe da possibilidade de alterar suas configurações na própria aplicação, pois, afinal, a aplicação pode ser configurável, porém, não se pode colocar qualquer coisa na configuração. E esse limite deve ser gerenciado pela aplicação, para que evite maiores problemas.

    Considerando a validação um ponto importante, seja para configuração, ou para o intercâmbio de informações, a validação, o contrato do documento se faz importante. E isso o XML dispõe dessa possibilidade. O JSON e o YAML tem algo parecido?

    Eu acho as três tecnologias interessantes. E cada uma tem seu ponto forte. Algumas tecnologias oferecerão performance, outras pouca portabilidade, e assim é a nossa área. 😉

    Do mais, e importante levantar os pontos, e acho seu pensamento válido.

    Abraços!

    Responder

  9. Concordo plenamente com você Elcio,

    Eu gosto bastante da configuração JSON e acho fascinante como a comunidade open source vem adotando também. O PHP, por exemplo, já adotou os métodos `json_encode` e `json_decode` como padrão em suas novas versões. Parsear JSON é a forma mais rápida (para o navegador) de parsear os dados (vale lembrar que “eval is evil”).

    Contudo, JSON também não é A solução e sim é uma DAS soluções para conversas entre os serviços web. Assim como o JSON funciona perfeitamente bem em quase todas as linguagens, o XML funciona bem com o JAVA e o .NET. Por isso do twitter disponibilizar os resultados em três formatos básicos.

    Se não me engano, em Ruby on Rails, podemos definir as saídas em JSON e XML nos controllers sem precisar de muita configuração (templates, models, etc), o que facilita a vida do desenvolvedor para criar web services bem resolvidos.

    Agora, configuração… sempre fui adepto de ter as configurações na linguagem em que está se trabalhando. No WordPress por exemplo, temos o wp-config.php. Em php, eu gosto de usar constantes e encapsular-las nos objetos quando necessário, mas isso é outro assunto.

    Já ouvi dizer: “configurações são em XML para que o usuário leigo consiga entender”. A minha reposta imediata foi o silêncio… Do meu ponto de vista não é o usuário leio que vai fazer essas configurações no sistema e mesmo que seja, trocar variáveis ou adicionar novas linhas não é tão absurdo como parece, a ponto do XML ser mais fácil que, por exemplo, o YAML.

    Responder
  10. Pingback: Tweets that mention XML não é a resposta -- Topsy.com

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *