XSLT e possíveis alternativas [fechado]

Eu dei uma olhada no XSLT para transformar um arquivo XML em outro (HTML, etc.). Agora, enquanto vejo que há benefícios para o XSLT (sendo uma ferramenta padronizada e usada), reluto por alguns motivos

• Os processadores XSLT parecem ser bastante grandes / com fome de recursos
• XML é uma má notação para programação e é disso que se trata o XSLT.

Ele não quer trollar o XSLT aqui, embora eu só queira salientar o que eu não gosto nele para lhe dar uma idéia do que eu esperaria de uma alternativa.

Tendo algum background do Lisp, pergunto-me se há maneiras melhores de transformar a estrutura da árvore com base em algum lisp. Eu já vi referências ao DSSSL, infelizmente a maioria dos links sobre o DSSSL está morta, então já é um desafio ver algum código que o ilustra. O DSSSL ainda está em uso? Lembro-me de ter instalado o openjade uma vez ao verificar o material do docbook.

A publicação no blog de Jeff Atwood parece sugerir o uso de Ruby em vez de XSLT.

Existem maneiras sãs de fazer transformações XML semelhantes ao XSLT em uma linguagem de programação não xml? Eu estaria aberto para entrada em

• Bibliotecas úteis para linguagens de script que facilitam transformações XML
• especialmente (mas não exclusivamente) linguagens de transformação do tipo lisp, ou Ruby, etc.

Algumas coisas que encontrei até agora:

• Alguns lugares na web apontaram o Linq como uma possível alternativa. Geralmente, eu tenho qualquer tipo de classificação, também daqueles que tiveram a melhor experiência com XSLT.
• Para o esquema http://cs.brown.edu/~sk/Publications/Papers/Published/kk-sxslt/ e http://www.okmij.org/ftp/Scheme/xml.html

É difícil avaliar tecnologias quando você não tem uma experiência profunda delas, mas é claro que é exatamente quando você precisa tomar suas decisões, portanto não há uma resposta simples para esse dilema.

Você cita duas preocupações: desempenho e usabilidade. Vou tentar abordar os dois abaixo.

Em primeiro lugar, desempenho. Obviamente, o desempenho depende não apenas do idioma, mas também da implementação e também da experiência dos usuários. Processadores XSLT diferentes podem variar muito em desempenho, e o mesmo processador pode variar muito, dependendo de como é usado (com o Saxon, por exemplo, muitas pessoas com problemas de desempenho costumam usá-lo com o DOM, o que é uma má combinação , e o desempenho pode aumentar dez vezes se você usar o modelo de árvore nativa do Saxon). Portanto, o primeiro conselho é não aceitar o desempenho de um boato, meça-o; e o segundo conselho é garantir que a pessoa que faz a medição tenha experiência suficiente para não cometer erros tolos. É mais fácil falar do que fazer.

De maneira grosseira, é possível separar tarefas de transformação em duas categorias: simples e complexas. Para transformações simples, com um bom processador XSLT, todo o tempo é gasto analisando e serializando, e o tempo de processamento XSLT dificilmente entra em cena. Como qualquer outra tecnologia incorre nos mesmos custos de análise e serialização, a escolha da tecnologia de transformação não fará grande diferença (exceto talvez para codificação de nível muito baixo usando streaming, mas poucas pessoas podem pagar a programação tempo e habilidades necessárias para implementá-lo). Para transformações complexas em documentos grandes, você começa a ter os mesmos problemas da programação SQL: alcançar um bom desempenho requer uma boa interação entre as habilidades e os conhecimentos do programador e os recursos do otimizador. Como no SQL, é ' É muito fácil, em uma linguagem de alto nível, escrever algumas instruções simples que resultam no processamento do trabalho por parte do processador. Mas também como no SQL, os programadores que sabem o que estão fazendo farão muito melhor do que os novatos.

Segundo, usabilidade. A sintaxe baseada em XML para XSLT é muito desanimadora para muitas pessoas no primeiro encontro com a linguagem. Mas há boas razões e benefícios reais para fazê-lo desta maneira: existe o argumento "modelo", que grande parte do código consiste em XML para ser gravado no documento de resultado, e a melhor maneira de escrever XML é em XML. E há o argumento da "reflexão"; em grandes sistemas complexos, é muito comum encontrar folhas de estilo que geram folhas de estilo. Depois, há o argumento "ferramentas"; se você estiver em uma loja XML, provavelmente possui muitas ferramentas XML, como editores direcionados à sintaxe, e é bom poder usar as mesmas ferramentas para lidar com seus programas e dados. As desvantagens acabam sendo bastante cosméticas em comparação: s o número de pressionamentos de tecla envolvidos na edição (facilmente corrigidos com uma boa ferramenta de edição) e a verbosidade do código (reduzindo sua legibilidade). A verbosidade é bastante reduzida no XSLT 2.0 com a introdução de recursos como expressões regulares e funções da folha de estilo: muitas folhas de estilo são reduzidas para metade ou um terço quando tiram o máximo proveito do XSLT 2.0.

Sua menção ao DSSSL me deixa com um sorriso irônico. Eu nunca usei o DSSSL, mas as histórias que ouvi foram que não tiveram êxito porque sua sintaxe era misteriosa e não relacionada à sintaxe dos dados (SGML). O uso de uma sintaxe XML para XSLT foi fortemente motivado pela experiência com DSSSL.

Há pessoas que amam o XSLT e outras que o odeiam. Sem surpresa, aqueles que o usam muito tendem a cair na primeira categoria. Aqueles que não gostam são geralmente aqueles que não aprenderam a "pensar da maneira XSLT". Você pode argumentar que uma linguagem de programação não deve afetar a maneira como você pensa, mas afeta: escrever em uma linguagem baseada em regras tem uma mentalidade diferente da escrita em uma linguagem imperativa. A primeira reação de muitos programadores é que eles se sentem menos no controle (descrevendo o problema, em vez de dizer ao computador o que fazer passo a passo). É muito semelhante à reação que você costumava ver quando as pessoas foram introduzidas pela primeira vez no SQL. Atualmente, as pessoas aprendem SQL mais cedo em suas carreiras, para que haja menos reajustes mentais.

Por fim, você deve escolher uma tecnologia baseada em critérios objetivos mensuráveis, não em reações de amor / ódio. É difícil fazer essas medições. Mas há muitas pessoas que usam o XSLT de maneira muito intensa e com muito sucesso, portanto não há dúvida de que isso pode ser feito.

Sem informações adicionais sobre o contexto, é difícil responder.

Ainda assim, não entendo por que você não deseja usar o XSLT. É a ferramenta certa para o trabalho e poderosa. Isso é feito especificamente para transformar um XML em outro.

Os processadores XSLT parecem ser bastante grandes / com fome de recursos

Você tem dados concretos para apoiar isso? Você implementou a solução usando o XSLT e descobriu que o XSLT é o gargalo que impossibilita a entrega do produto e atende a todos os requisitos não funcionais relacionados ao desempenho?

Sem dados estatísticos e criação de perfil, não é possível afirmar razoavelmente que uma determinada solução não funcionará. Os requisitos não funcionais são razoáveis ​​o suficiente? Você prefere desperdiçar, digamos, dez dias de trabalho dos desenvolvedores para ganhar algumas centenas de milissegundos substituindo o XSLT por outra alternativa? Será que vale a pena?

XML é uma má notação para programação e é disso que se trata o XSLT.

Então, você deseja transformar um XML em outro, mas não deseja usar o XSLT porque "XML é uma notação ruim"?

Se o fato de você usar XML como um tipo de linguagem de programação o incomoda tanto, não o veja como programação, mas como um monte de regras de transformação.

Você nem precisa escrever XSLT manualmente. Existem muitos editores de ETL que permitem mapear graficamente um XML para outro: nenhuma programação é necessária. Alguns deles usam XSLT como saída.

Se você estiver usando o XSLT para gerar XML com base no XSLT bruto e em alguns parâmetros que você está passando para o mecanismo XSLT, será muito mais fácil entender e manter o uso de uma abordagem XML de modelo.

Eu estive em um projeto em que o Bigode foi usado para substituir o XSLT e o resultado foi arquivos XML básicos muito mais simples que todos podiam editar e ajustar, em vez de o trabalho do projeto ser passado para uma ou duas almas corajosas, que ficavam em silêncio total com gotas de suor escorrendo ...

A abordagem do modelo não é adequada para uso quando o XML base também é um dado válido por si só e o XSLT está sendo usado para fornecer uma representação alternativa ou uma extração do XML de origem.

XML não é uma linguagem de programação

XML é uma maneira de transferir / transportar dados.
o que uma instrução XSLT faz é usar o Xpath para consultar os Dados de uma maneira específica e colocá-los em outro Objeto / Documento de Transporte de Dados.

E / OU

O XSLT pode transformar seu XML em HTML, que é outra maneira de exibir / transportar os dados contidos em um documento XML.

Se você deseja alterar o XML ou criar um documento XML, pode usar qualquer número de idiomas: C #, VB, Ruby, Etc.

normalmente, quando você usa um arquivo XSLT para transformar um documento XML, ainda possui o documento XML original, na verdade não altera o documento original, cria um novo.

Trabalhei em vários sistemas de processamento XML que combinam bibliotecas XSLT com Java ou C ++ para as partes nas quais o XSLT não é tão bom. Existem bibliotecas que obtêm um desempenho XSLT muito bom, mesmo em arquivos XML de 20 MB, no entanto, o XSLT tem algumas limitações com contexto, variáveis ​​e padrões de cadeia realmente complexos. Cada sistema em que trabalhei tinha algumas coisas feitas em Java / C ++ porque o contexto era importante ou alguma expressão complexa de regex ajudou. Meu argumento é que o XSLT, mais algum código adicional na sua linguagem de escolha, é uma boa maneira de transformar XML.