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.

Tagged with →  
Share →

16 Responses to XML não é a resposta

  1. [...] Sobre XML não é a resposta [...]

  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.

  3. Alexandre disse:

    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”

  4. Pirolla disse:

    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.

    • elcio disse:

      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.

  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

  6. Abraao disse:

    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.

  7. Igor Escobar disse:

    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

  8. Edgar disse:

    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!

  9. dgmike disse:

    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.

  10. [...] This post was mentioned on Twitter by Júlio César Martini, J.G. Valério, Elcio Ferreira, emerson vinicius, Fabiano de Freitas and others. Fabiano de Freitas said: ♺ @elcio: XML não é a resposta – http://bit.ly/cdrmL4 [...]

  11. Marcelo Iepsen disse:

    Élcio, os links de search para atom e json estão linkando para o html.

    Abraço.

  12. Na maioria das linguagens ler um json é sempre mais facil que parser um XML.

    Em ruby YAML é uma consideração bem familiar para os programadores, no rails as config de banco de dados estão em um arquivo YAML

Deixe uma resposta

O seu endereço de email não será publicado Campos obrigatórios são marcados *

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>