Quais alternativas utilizáveis para a sintaxe XML você conhece?[fechado]
https://stackoverflow.com/questions/51492
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
Para mim utilizável significa que:
- está sendo usado no mundo real
- possui suporte a ferramentas.(pelo menos algum editor simples)
- tem sintaxe legível por humanos (sem colchetes angulares, por favor)
Também quero que seja o mais próximo possível do XML, ou seja,deve haver suporte para atributos e também para propriedades.Então não YAML por favor.Atualmente, apenas um idioma correspondente me vem à mente - JSON.Você conhece alguma outra alternativa?
Solução
YAML é um superconjunto 100% de JSON, então não faz sentido rejeitar YAML e então considerar JSON.O YAML faz tudo o que o JSON faz, mas o YAML também oferece muito mais (como referências).
Não consigo pensar em nada que o XML possa fazer que o YAML não possa, exceto validar um documento com um DTD, o que, na minha experiência, nunca valeu a pena.Mas o YAML é muito mais rápido e fácil de digitar e ler do que o XML.
Quanto aos atributos ou propriedades, se você pensar bem, eles realmente não "adicionam" nada...é apenas um atalho de notação para escrever algo como um atributo do nó em vez de colocá-lo em seu próprio nó filho.Mas se você gosta dessa conveniência, muitas vezes você pode emulá-la com listas/hashes embutidos do YAML.Por exemplo:
<!-- XML -->
<Director name="Spielberg">
<Movies>
<Movie title="Jaws" year="1975"/>
<Movie title="E.T." year="1982"/>
</Movies>
</Director>
# YAML
Director:
name: Spielberg
Movies:
- Movie: {title: E.T., year: 1975}
- Movie: {title: Jaws, year: 1982}
Para mim, o luxo de não ter que escrever cada tag de nó duas vezes, combinado com a liberdade de todo o lixo entre colchetes angulares, torna o YAML uma escolha preferida.Na verdade, também gosto da falta de atributos de tag formais, pois isso sempre me pareceu uma área cinzenta do XML que introduzia desnecessariamente dois conjuntos de sintaxe (tanto ao escrever quanto ao percorrer) para essencialmente o mesmo conceito.YAML acaba com essa confusão completamente.
Outras dicas
JSON é uma alternativa muito boa e existem ferramentas para isso em vários idiomas.E é muito fácil de usar em clientes web, pois é javascript nativo.
eu encontrei Expressões S ser uma ótima maneira de representar dados estruturados.É um formato muito simples, fácil de gerar e analisar.Não suporta atributos, mas como YAML e JSON, não é necessário.Os atributos são simplesmente uma forma do XML limitar a verbosidade.Formatos mais simples e limpos simplesmente não precisam deles.
DR
O Prolog não foi mencionado aqui, mas é o melhor formato que conheço para representar dados.Os programas Prolog, essencialmente, descrevem bancos de dados, com relacionamentos complexos entre entidades.Prolog é extremamente simples de analisar, cujo provavelmente único rival são as expressões S neste domínio.
Versão completa
Os programadores muitas vezes "esquecem" em que realmente consiste o XML.Geralmente referindo-se a um subconjunto muito pequeno do que é.XML é um formato muito complexo, com pelo menos estas partes: Linguagem de esquema DTD, Linguagem de esquema XSD, Linguagem de transformação XSLT, Linguagem de esquema RNG e XPath (mais XQuery) linguagens - todas elas são parte integrante do padrão XML.Além disso, existem alguns apócrifos como E4X.Cada um deles com suas próprias versões, algumas sobreposições, incompatibilidades etc.Muito poucos analisadores XML existentes implementam todos eles.Sem mencionar as múltiplas peculiaridades e bugs das análises populares, algumas levando a problemas de segurança notáveis, como https://en.wikipedia.org/wiki/XML_external_entity_attack .
Portanto, procurando por um XML alternativa não é uma ideia muito boa.Você provavelmente não quer lidar com XML.
YAML é, provavelmente, a segunda pior opção.Não é tão grande quanto XML, mas também foi projetado na tentativa de cobrir todas as bases...mais de dez vezes cada...de maneiras diferentes e únicas que ninguém jamais poderia conceber.Ainda não ouvi falar de um analisador YAML funcionando corretamente.Ruby, a linguagem que usa muito YAML, teve notoriamente estragado por causa disso.Todos os analisadores YAML que vi até agora são cópias de líbiaml, que é em si um tipo de analisador escrito à mão (não gerado a partir de uma descrição formal), com um código cuja correção é muito difícil de verificar (funções que abrangem centenas de linhas com fluxo de controle complicado).Como já foi mencionado, ele contém JSON completamente...além de um punhado de técnicas de codificação Unicode...dentro do mesmo documento e provavelmente um monte de outras coisas que você não quer ouvir.
JSON, por outro lado, é completamente diferente dos outros dois.Você provavelmente pode escrever um analisador JSON enquanto espera pelo download do artefato do analisador JSON do seu Maven Nexus.Pode fazer muito pouco, mas pelo menos você sabe do que é capaz.Sem surpresas.(Exceto algumas discrepâncias relacionadas ao escape de caracteres em strings e codificação dupla).Sem explorações secretas.Você não pode escrever comentários nele.Strings multilinhas parecem ruins.O que quer que você queira dizer com distinção entre propriedades e atributos, você pode implementar por meio de dicionários mais aninhados.
Suponha que você queira corrigir o que o XML prejudicou...bem, então coisas populares como YAML ou JSON não funcionarão.De alguma forma, a moda e o pensamento racional se separaram na programação em meados dos anos setenta.Então, você terá que voltar para onde tudo começou com McCarthy, Hoare, Codd e Kowalski, descobrir o que você está tentando representar e então ver qual é a melhor técnica de representação que existe para o que quer que você esteja. tentando representar :)
Eu recomendaria JSON ...mas como você já mencionou isso, talvez você devesse dar uma olhada Buffers de protocolo do Google.
Editar:Os buffers de protocolo são feitos para serem usados programaticamente (existem ligações para c++, java, python ...), portanto, podem não ser adequados para o seu propósito.
Suas demandas são um pouco impossíveis.Você quer algo próximo ao XML, mas provavelmente rejeita o equivalente mais próximo que não possui colchete angular (YAML).
Por mais que eu não goste, por que não usar XML?Você nunca deveria ter que realmente ler XML (além da depuração, suponho), há uma quantidade absurda de ferramentas para isso.
Praticamente tudo que não seja XML não será tão amplamente utilizado, portanto, haverá menos suporte a ferramentas.
JSON é provavelmente equivalente, mas é igualmente ilegível.mas, novamente, você nunca deveria precisar lê-lo (carregá-lo em qualquer idioma que estiver usando e deve ser transformado em matrizes/dictos/variáveis/qualquer coisa nativa).
Ah, eu encontro JSON distante mais agradável de analisar do que XML:Eu usei-o em Javascript e no módulo simplejson Python - cerca de um comando e é bem transformado em um ditado Python nativo ou em um objeto Javascript (daí o nome!)
Há AXÔNIO que cobrem o melhor de XML e JSON.Vamos explicar isso em vários exemplos.
AXON pode ser considerado uma forma mais curta de dados XML.
XML
<person>
<name>Frank Martin</name>
<age>32</age>
</person>
AXÔNIO
person{
name{"Frank Martin"}
age{32}}
ou
person
name:
"Frank Martin"
age:
32
XML
<person name="Frank Martin" age="32" />
AXÔNIO
person{name:"Frank Martin" age:32}
ou
person
name: "Frank Martin"
age: 32
AXON contém alguma forma de JSON.
JSON
{"name":"Frank Martin" "age":32 "birth":"1965-12-24"}
AXÔNIO
{name:"Frank Martin" age:32 birth:1965-12-24}
AXON pode representar uma combinação de dados semelhantes a XML e JSON.
AXÔNIO
table {
fields {
("id" "int") ("val1" "double") ("val2" "int") ("val3" "double")
}
rows {
(1 3.2 123 -3.4)
(2 3.5 303 2.4)
(3 2.3 235 -1.2)
}
}
ou
table
fields
("id" "int")
("val1" "double")
("val2" "int")
("val3" "double")
rows
(1 3.2 123 -3.4)
(2 3.5 303 2.4)
(3 2.3 235 -1.2)
Está disponível a biblioteca python pyaxão agora.
Eu penso Prata transparente é uma alternativa muito boa.Eles até têm uma página de comparação aqui e uma lista de projetos que use isso
Para armazenar dados semelhantes a código, LES (Loyc Expression Syntax) é uma alternativa emergente.Tenho notado que muitas pessoas usam XML para construções semelhantes a códigos, como sistemas de construção que suportam condicionais, invocações de comandos e, às vezes, até loops.Esse tipo de coisa parece natural no LES:
// LES code has no built-in meaning. This just shows what it looks like.
[DelayedWrite]
Output(
if version > 4.0 {
$ProjectDir/Src/Foo;
} else {
$ProjectDir/Foo;
}
);
Porém, ele ainda não possui um ótimo suporte a ferramentas;atualmente a única biblioteca LES é para C#.Atualmente, apenas um aplicativo usa LES: LLLPG.Ele suporta "atributos", mas eles são como atributos C# ou anotações Java, não atributos XML.
Em teoria, você poderia usar LES para dados ou marcação, mas não existem padrões sobre como fazer isso:
body {
'''Click here to use the World's '''
a href="http://google.com" {
strong "most popular"; " search engine!"
};
};
point = (2, -3);
tasteMap = { "lemon" -> sour; "sugar" -> sweet; "grape" -> yummy };
Se você é alérgico a colchetes angulares, então JSON, HDF (Prata Transparente) e OGDL são os únicos que conheço de imediato.
Depois de pesquisar um pouco no Google, também encontrei uma lista de alternativas aqui:
http://web.archive.org/web/20060325012720/www.pault.com/xmlalternatives.html
YAML é um formato extremamente completo e geralmente legível por humanos, mas sua cura de Aquiles é a complexidade, conforme demonstrado pelas vulnerabilidades do Rails que vimos neste inverno.Devido à sua onipresença em Ruby como linguagem de configuração, Tom Preston-Werner, famoso no Github, se esforçou para criar uma alternativa sensata chamada TOML.Ele ganhou grande tração imediatamente e possui ótimo suporte para ferramentas.Eu recomendo fortemente que qualquer pessoa que esteja olhando para YAML dê uma olhada:
AFAIK, JSON e YAML são exatamente equivalentes em termos de estrutura de dados.YAML tem menos colchetes, aspas e outras coisas.Portanto, não vejo como você está rejeitando um e mantendo o outro.
Além disso, não vejo como os colchetes angulares do XML são menos "legíveis por humanos" do que os colchetes, colchetes e aspas do JSON.
Existem realmente muitas alternativas ao XML, mas o principal problema com muitas delas parece ser que as bibliotecas podem não estar disponíveis para todas as linguagens de escolha e as bibliotecas são relativamente trabalhosas para implementar.
A análise de uma estrutura de árvore em si pode não ser tão agradável, se comparada a pares de valores-chave, por exemplo.tabelas hash.Se uma instância de tabela hash atender ao requisito de que todas as suas chaves sejam strings e todos os seus valores sejam strings, será relativamente fácil implementar hashtable2string() e string2hashtable().
Tenho utilizado a serialização de tabelas hash em AJAX entre PHP e JavaScript e o formato que desenvolvi chama-se ProgFTE (Programmer Friendly text Exchange) e está descrito em:
http://martin.softf1.com/g/n//a2/doc/progfte/index.html
Pode-se encontrar uma versão Ruby da implementação ProgFTE como parte da biblioteca Kibuvits Ruby:http://rubyforge.org/projects/kibuvits/
