XML para quê? Conheça YAML, o primo esperto das linguagens de markup.
Conhece a anedota? Conta que um programador estava tentando resolver um problema: ele tinha um sistema que precisava manipular e enviar informação estruturada para outros clientes. Num instante de pura sagacidade, ele pensou “Já sei. Vou usar XML!”. No instante seguinte, de pura decepção, ele constatou: “Agora eu tenho dois problemas. Não bastasse meu problema original, eu vou usar XML.”
De todos os alfabetos gastos em tecnologias que construiam “em cima” do XML (XQuery, XPath, XSL, XML-RPC, X-Men, Xuxa, sei lá) não consigo lembrar de nenhum que traga algo novo. Parece que é o tipo de coisa que cai na categoria “problemas inventados pelos vendors de software para que eu possa continuar justificando lucros trimestrais de US$4 bilhões.”
Tudo que eu e o programador da anedota precisamos é de um sistema que possa passar informação de um jeito estruturado. Se puder ser facilmente lido como texto, tanto melhor. Ninguém merece ter que ficar editando arquivo CSV, não é mesmo?
Que tal a possibilidade de ver um registro de uma fatura num formato assim?
invoice: 34843
date : 2001-01-23
bill-to: &id001
given : Chris
family : Dumars
address:
lines: |
458 Walkman Dr.
Suite #292
city : Royal Oak
state : MI
postal : 48046
ship-to: *id001
product:
- sku : BL394D
quantity : 4
description : Basketball
price : 450.00
- sku : BL4438H
quantity : 1
description : Super Hoop
price : 2392.00
tax : 251.42
total: 4443.52
Esse é um documento YAML, válido. Bonitinho, né? Pena que ninguém mais usa isso por aí… e de que adianta ser capaz de emitir algo assim, se ninguém é capaz de receber? Vou ter que continuar usando XML?
Não necessariamente. Especialmente se está mexendo com web e já ouviu falar de uma outra darling das notações de marcação, JSON.
JSON, essa você já deve ter ouvido falar. Seu browser mastiga isso com uma facilidade tremenda:
{"student": {
"first name": "John",
"last name": "Smith",
"course": {
"report": [
{"Subject": "Math", "grade": "A"},
{"Subject": "English", "grade": "C"},
{"Subject": "Arts", "grade": "F"}]}}}
}
É só pedir para o seu interpretador Javascript avaliar essa string, e você tem um objeto que pode processar, e apresentar um relatório lindo para os pais do John, que vão dar uma bronca nele por ele não largar do computador e não ter aprendido a desenhar flores em aquarela.
Deixa eu contar o pulo do gato: todo JSON válido também é YAML. A notação usada em JSON é usada para descrever inline collections em YAML. Se você tiver uma string que seja a representação de um objeto em JSON, ele será visto como um objeto pelo seu parser de YAML (escolha aqui seu parser, na sua linguagem/plataforma favorita).
O que se ganha com isso? Um exemplo: validação e manipulação de formulários. Que tal a possibilidade de não só validar os dados no cliente, mas também pegar os campos de um formulário, verificar se o objeto está consistente, transformar em uma string JSON (usando um emitter apropriado) e enviar para o servidor essa string? Depois, o seu parser de YAML vai te montar um objeto, o qual pode ser muito mais facilmente validado e verificado.
Para quem quiser fazer formulários onde campos podem ser livremente adicionados ou removidos, ou usar toneladas de AJAX em seu aplicativo web, a combinação JSON + YAML funciona e é uma mão na roda.
Raphael,
Concordo com você que pra muita coisa XML é overkill. Por exemplo, pra passar registros como os exemplos que você mostrou.
Mas não consigo ver este tipo de tecnologia que você mostrou substituindo XML. Por exemplo, não consigo enxergar como este tipo de tecnologia representaria um texto com formatação (por exemplo, HTML). Ou tipos de informações mais estruturadas, com interdependências de validações. Você tem exemplos disso?
Um abraço,
Leonardo Garcia
XML para quê? Conheça YAML, o primo esperto das linguagens de markup. « Log
XML para quê? Conheça YAML, o primo esperto das linguagens de markup
Raphael, fico bem feliz em ver que finalmente vc escreveu um review tecnológico!
Não conhecia YAML, mas andei brincando um pouco com JSON. De fato, para transferência de dados estruturados, JSON resolve muito bem o problema e é mais simples e mais direto do que XML. Se formos utilizar esta transferência em um ambiente com Javascript, a vantagem é dupla, já que javascript avalia e entende JSON. E parsear XML em js é um porre.
Mas concordo com o Leo quando ele fala que talvez para dados mais complexos, para armazenamento e coisas onde você precise de mais detalhes, XML ainda seja melhor.
Como eu disse no post sobre diversidade, acho que é importante usar as melhores ferramentas em cada momento. No caso, JSON e XML tem o propósito interessante de estruturar informação de uma forma legível e clara. Me parecem que elas podem coexistir em domínios separados.
[]s
Léo e Miguel,
tem razão. Não recomendaria a ninguém que largasse tudo que foi feito em XML e partisse para outra coisa. Só acho que ainda está para surgir alguma aplicação onde todas as coisas que XML diz resolver não tenha sido resolvidas por outros sistemas, menores.
Quanto a validação de esquema: tirei da wikipedia o que vai abaixo.
Ah… e quando eu digo que não há nada de novo em XML, é pelo seguinte:
XML usa a idéia do DOM: uma árvore, com elementos cujos filhos são outros elementos. Isso não é novo. S-expressions já são assim.
(html
(head
(title “Example page”)
)
(body
(h1 style “color:red” “This is a really pointless example”)
(p
“I can’t think of anything exciting to say on this line.”
(br)
“Nor this one.”
)
)
)
O trabalho de um interpretador LISP, por exemplo, consiste justamente em parsear o seu arquivo e montar a AST. Isso é, na teoria e na prática, justamente a “validação de um schema”.
A principal vantagem do XML é que é meta-formato padronizado.
Por ser um meta-formato e não um formato ele lhe dá a flexibilidade de criar suas estruturas hierárquicas da maneira como você quiser.
Por ser padronizado você pode pegar o padrão e implementar parsers em qualquer plataforma, podendo então trocar dados estruturados entre COBOL, Java, .NET, Python, Ruby, etc.
E é claro, hoje os parsers já estão todos implementados, você nunca precisará codificar algo na mão para ler um XML em praticamente 100% das plataformas de desenvolvimento.
XML surgiu para prover interoperabilidade, e isto ele faz muito bem. (e de quebra ainda tem a questão da validação que ele faz automaticamente também, ou melhor os parsers são obrigados pela spec).
Graças a estas características é possível você criar formatos para informações hierarquisadas, sem você se preocupar em como Ler ou Escrever (pois as APIs já estão prontas). E ter a certeza de que qualquer outro sistema pode ler estas informações (validadas) facilmente.
O XML-RPC que foi citado apenas implementa RPC se valendo de XML para ser o formato padrão entre uma invocação Java -> C++ por exemplo. Graças ao XML os projetistas não precisaram se preocupar em criar parsers, formatos fechados, etc.
Quanto a verbosidade de XML, qualquer XML de tamanho razoável provavelmente hoje é gerado programaticamente e não por mãos humanas. E leitores XML existem em número infinitamente superior aos editores de qualquer outro formato concorrente.
O que eu sinto falta no YAML é a validação sintática que qualquer editor (para programadores) pode fazer em um XML. Não gostaria de ter que rodar meu programa e ver um erro só em runtime para descobrir que troquei um “:” por um “;”.
No mundo java recomendo a API http://www.dom4j.org/
Não, Bruno, de novo não!
Vamos deixar assim: o que motivou o post foi a minha busca por uma esquema prático para passar dados de um cliente web para o servidor. E usando o esquema JSON + YAML, eu também não escrevo nada em nenhum desses formatos.
As libs de JS se encarregam de emitir o código JSON, e o parser de YAML se encarrega de construir o objeto para mim.
Cheers.
Mas nem foi para contradizer as vantagens que você levantou não
Foi mais para complementar o post (bem interessante por sinal) com as informações sobre XML.
Pena que ninguém mais usa isso por aí…
Eu uso! Eu uso!
O Framework PHP Symfony utiliza o YAML.
http://www.symfony-project.com