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.

Valeu, Augusto! Esclarecedor. Já estou estudando.

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.

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”

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.

praticamente 2 linhas em Ruby com Rails ele cuspe json e xml

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

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

Corrigido. Obrigado Marcelo!

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!

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.

Abraço.

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