XSLT e possibili alternative [chiuso]


15

Ho dato un'occhiata a XSLT per trasformare un file XML in un altro (HTML, ecc.). Ora mentre vedo che ci sono benefici per XSLT (essendo uno strumento standardizzato e usato) sono riluttante per un paio di motivi

  • I processori XSLT sembrano essere abbastanza grandi / affamati di risorse
  • XML è una cattiva notazione per la programmazione e questo è tutto ciò che riguarda XSLT.

Non voglio trollare XSLT qui, anche se voglio solo sottolineare ciò che non mi piace al riguardo per darti un'idea di cosa mi aspetterei da un'alternativa.

Avendo un po 'di background in Lisp, mi chiedo se ci siano modi migliori per le trasformazioni della struttura ad albero basate su alcuni lisp. Ho visto riferimenti a DSSSL, purtroppo la maggior parte dei collegamenti su DSSSL sono morti, quindi è già difficile vedere qualche codice che lo illustri. DSSSL è ancora in uso? Ricordo di aver installato openjade una volta durante il checkout di documenti docbook.

Il post sul blog di Jeff Atwood sembra suggerire l'uso di Ruby invece di XSLT.

Esistono modi sani per eseguire trasformazioni XML simili a XSLT in un linguaggio di programmazione non xml? Sarei aperto per input su

  • Librerie utili per linguaggi di scripting che facilitano le trasformazioni XML
  • specialmente (ma non esclusivamente) linguaggi di trasformazione lisp-like, o Ruby, ecc.

Alcune cose che ho trovato finora:


Uso HXT e Haskell abbastanza spesso, è molto piacevole
Daniel Gratzer,

5
In tutta onestà, non è Jeff Atwood a sostenere Ruby, sta citando Martin Fowler che preferisce Ruby. Il post originale di Fowler è qui: martinfowler.com/bliki/MovingAwayFromXslt.html Ed è stato scritto 10 anni fa nel 2003 - Penso che XSLT 2.0 sia uscito nel 2007 e con molti miglioramenti, e XPath 2.0 nel 2010.
FrustratedWithFormsDesigner

Risposte:


18

È difficile valutare le tecnologie quando non ne hai una profonda esperienza, ma ovviamente è esattamente quando devi prendere le tue decisioni, quindi non c'è una risposta semplice a quel dilemma.

Citi due preoccupazioni: prestazioni e usabilità. Proverò ad affrontare entrambi sotto.

Innanzitutto, le prestazioni. Le prestazioni ovviamente dipendono non solo dalla lingua ma anche dall'implementazione e anche dalla competenza degli utenti. Processori XSLT diversi possono variare notevolmente nelle prestazioni e lo stesso processore può variare ampiamente a seconda del modo in cui viene utilizzato (con Saxon, ad esempio, si scopre molto spesso che le persone che hanno problemi di prestazioni lo usano con DOM, che è una combinazione scadente e le prestazioni possono aumentare di dieci volte se si utilizza invece il modello ad albero nativo di Saxon). Quindi il primo consiglio è di non prendere le prestazioni per sentito dire, misurale; e il secondo consiglio è quello di assicurarsi che la persona che effettua la misurazione abbia abbastanza esperienza per non commettere errori sciocchi. Più facilmente a dirsi che a farsi.

In modo grossolano, puoi separare i lavori di trasformazione in due categorie: semplici e complessi. Per trasformazioni semplici, con un buon processore XSLT il tempo è tutto dedicato all'analisi e alla serializzazione e il tempo di elaborazione XSLT difficilmente entra in scena. Poiché qualsiasi altra tecnologia comporta gli stessi costi di analisi e serializzazione, la scelta della tecnologia di trasformazione non farà una grande differenza (tranne forse per la codifica di livello molto basso che utilizza lo streaming, ma non molte persone possono permettersi la programmazione tempo e competenze necessarie per implementarlo). Per trasformazioni complesse su documenti di grandi dimensioni, inizi a riscontrare gli stessi problemi della programmazione SQL: raggiungere buone prestazioni richiede una buona interazione tra le competenze e le conoscenze del programmatore e le capacità dell'ottimizzatore. Come con SQL, è ' È molto facile in un linguaggio di così alto livello scrivere alcune semplici affermazioni che comportano che il processore debba svolgere una grande quantità di lavoro. Ma anche come con SQL, i programmatori che sanno cosa stanno facendo faranno molto meglio dei principianti.

Secondo, usabilità. La sintassi basata su XML per XSLT è molto scoraggiante per molte persone al primo incontro con la lingua. Ma ci sono buone ragioni e vantaggi reali per farlo in questo modo: c'è l'argomento "template", secondo cui gran parte del codice è costituito da XML da scrivere nel documento di risultato e il modo migliore per scrivere XML è in XML. E c'è l'argomento "riflessione"; in grandi sistemi complessi, è molto comune trovare fogli di stile che generano fogli di stile. Poi c'è l'argomento "strumenti"; se ti trovi in ​​un negozio XML, probabilmente hai molti strumenti XML come gli editor diretti dalla sintassi, ed è bene poter usare gli stessi strumenti per gestire i tuoi programmi e i tuoi dati. Gli svantaggi si rivelano piuttosto estetici rispetto: s il numero di sequenze di tasti coinvolte nella modifica (facilmente risolvibile con un buon strumento di modifica) e la verbosità del codice (che riduce la sua leggibilità). La verbosità è notevolmente ridotta in XSLT 2.0 con l'introduzione di caratteristiche come le espressioni regolari e le funzioni del foglio di stile: molti fogli di stile sono ridotti della metà o di un terzo quando sfruttano appieno XSLT 2.0.

La tua menzione di DSSSL mi lascia con un sorriso ironico. Non ho mai usato DSSSL, ma le storie che ho sentito sono state insensate perché la sua sintassi era arcana e non correlata alla sintassi dei dati (SGML). L'uso di una sintassi XML per XSLT è stato fortemente motivato dall'esperienza con DSSSL.

Ci sono persone che adorano XSLT e ci sono persone che lo odiano. Non sorprende che coloro che lo usano molto tendano a rientrare nella prima categoria. A chi non piace è generalmente chi non ha imparato a "pensare in modo XSLT". Si potrebbe sostenere che un linguaggio di programmazione non dovrebbe influenzare il modo in cui si pensa, ma lo fa: scrivere in un linguaggio basato su regole richiede una mentalità diversa dalla scrittura in un linguaggio imperativo. La prima reazione di molti programmatori è che si sentono meno in controllo (descrivendo il problema, piuttosto che dire al computer cosa fare passo dopo passo). È molto simile alla reazione che hai visto quando le persone sono state introdotte per la prima volta a SQL. In questi giorni, le persone imparano SQL in precedenza nella loro carriera, quindi è necessario un minor riaggiustamento mentale.

Alla fine, dovresti scegliere una tecnologia basata su criteri misurabili oggettivi, non su reazioni di amore / odio. È difficile effettuare tali misurazioni. Ma ci sono molte persone che usano XSLT in modo molto intenso e con grande successo, quindi non c'è dubbio che possa essere fatto.


2
Il termine più comune per "linguaggio basato su regole" è un linguaggio dichiarativo.
Daniel Gratzer,

@Michael Kay - Ben messo. Personalmente adoro XSLT e lo uso con C #. Inoltre lo uso con XSL-FO per produrre documenti PDF. XSLT è potente, molto potente, permettendomi di convertire rapidamente grandi quantità di dati in HTML, XSL-FO, XML o Text.
PhillyNJ,

3

Senza ulteriori informazioni sul contesto, è difficile rispondere.

Tuttavia, non capisco perché non vuoi usare XSLT. È lo strumento giusto per il lavoro e potente. Viene fatto specificamente per trasformare un XML in un altro.

I processori XSLT sembrano essere abbastanza grandi / affamati di risorse

Hai dati concreti per supportarlo? Hai implementato la soluzione utilizzando XSLT e hai scoperto che XSLT è il collo di bottiglia che rende impossibile consegnare il prodotto soddisfacendo tutti i requisiti non funzionali relativi alle prestazioni?

Senza dati statistici e profilazione, non si può ragionevolmente affermare che una determinata soluzione non funzionerà. I requisiti non funzionali sono abbastanza ragionevoli? Preferiresti sprecare, diciamo, dieci giorni di lavoro degli sviluppatori per guadagnare qualche centinaia di millisecondi sostituendo XSLT con un'altra alternativa? Ne vale la pena?

XML è una cattiva notazione per la programmazione e questo è tutto ciò che riguarda XSLT.

Quindi vuoi trasformare un XML in un altro, ma non vuoi usare XSLT perché "XML è una cattiva notazione"?

Se è il fatto che usi XML come una sorta di linguaggio di programmazione che ti infastidisce così tanto, consideralo non come una programmazione, ma piuttosto un mucchio di regole di trasformazione.

Non hai nemmeno bisogno di scrivere XSLT a mano. Esistono molti editor ETL che possono permetterti di mappare graficamente un XML in un altro: nessuna programmazione richiesta in alcun modo. Alcuni usano XSLT come output.


Ho riscontrato problemi di risorse con i fogli basati su XSLT, sono stati creati con uno strumento grafico ma ha smesso di funzionare con file più grandi.
Wirrbel,

1
allora probabilmente ci sono problemi con i tuoi XSLT filenon XSLT Transformationsstessi
Malachi,

Ora non sto condannando XML, in effetti penso che sia appropriato per la rappresentazione dei dati (specialmente per il markup). Come "linguaggio di programmazione" - e XSLT è un linguaggio di programmazione specifico del dominio - è scomodo. <xsl: qualunque> Tag, metalinguaggi (come xpath, $ notation, ecc.) negli attributi della query, tutto ciò che non è mappato in XML viene inserito tra virgolette di attributi. Per un'impressione di una rappresentazione di s-espressione di XML: blog.getprismatic.com/blog/2013/1/22/… in tale distanza XML e proglang possono funzionare in modo
apparente

1

Se si utilizza XSLT per generare XML basato su XSLT non elaborato e su alcuni parametri che si stanno passando al motore XSLT, l'utilizzo di un approccio XML basato su modelli è molto più semplice da comprendere e mantenere.

Sono stato su un progetto in cui Moustache è stato usato per sostituire XSLT e il risultato sono stati file XML di base molto più semplici che tutti potevano modificare e adattare, piuttosto che quel lavoro del progetto veniva passato a una o due anime coraggiose, che si sedevano in totale silenzio con gocce di sudore che si riversano ...

L'approccio del modello non è adatto all'uso quando l'XML di base è anche un dato valido a sé stante e che XSLT viene utilizzato per fornire una rappresentazione alternativa o un estratto dall'XML di origine.


ti dispiacerebbe spiegare di più su ciò che fa e perché lo consigli come rispondere alla domanda posta? Le "risposte solo link" non sono del tutto benvenute allo Stack Exchange
moscerino del

1
risposta rivista in linea con il tuo feedback
Michael Shaw,

0

XML non è un linguaggio di programmazione

XML è un modo per trasferire / trasportare dati.
ciò che fa un'istruzione XSLT è usare Xpath per interrogare i dati in un modo specifico e metterli in un altro oggetto / documento di trasporto dati.

E / O

XSLT può trasformare il tuo XML in HTML, che è un altro modo per visualizzare / trasportare i dati contenuti in un documento XML.

se stai cercando di modificare l'XML o creare un documento XML, puoi utilizzare un numero qualsiasi di lingue: C #, VB, Ruby, ecc.

di solito quando usi un file XSLT per trasformare un documento XML hai ancora il documento XML originale, non cambi il documento originale, ma ne crei davvero uno nuovo.


1
Wikipedia dice: "XSLT è un linguaggio completo di Turing, il che significa che può specificare qualsiasi calcolo che può essere eseguito da un computer". Non ho mai detto che XML fosse di per sé un linguaggio di programmazione.
Wirrbel,

hai detto "XML è una cattiva notazione per la programmazione" nei linguaggi di programmazione che ho usato puoi estrarre i dati da file XML piuttosto facilmente. XSLT sta guadagnando terreno grazie alla possibilità di eseguire molti calcoli e di distribuire tali dati a un altro oggetto / documento di trasporto dati. è come da SQL a SQL Server può fare molte cose ma è principalmente back-end, non front-end. SQL come XSLT, interroga i dati in un modo specifico, ma non vuoi mai dare i risultati di quella query come un rapporto, vuoi inviare le informazioni a un generatore di rapporti
Malachi,

2
XSLT non esegue query sui dati, XPATH esegue le query. XSLT non è un linguaggio dichiarativo che definisce le istruzioni su XML analizzato?
PhillyNJ,

XSLT definisce le regole di trasformazione basate su modelli per i quali può usare Xpath. Cioè puoi avere costrutti di programmazione di alto livello come xsl:for-each xsl:apply-templates, xsl:if xsl:call-template xsl:value-ofper definire regole di trasformazione.
Wirrbel,

1
@PhilVallone Sono d'accordo. Ho sbagliato lì. wirrbel, non ho intenzione di discutere con te su ciò che XSLT / XSL è e non lo è, se vuoi trasformare il tuo documento XML in un altro documento XML, vuoi usare XSLT / XSL.
Malachi,

0

Ho lavorato su più sistemi di elaborazione XML che combinano librerie XSLT con Java o C ++ per le parti in cui XSLT non è altrettanto bravo. Ci sono librerie che ottengono ottime prestazioni XSLT anche su file XML da 20 MB, tuttavia XSLT presenta alcune limitazioni con contesto, variabili e schemi di stringhe davvero complessi. Ogni sistema su cui ho lavorato ha fatto alcune cose in Java / C ++ perché il contesto era importante o alcune espressioni regex complesse hanno aiutato. La mia cosa da asporto è che XSLT più un codice aggiuntivo nella tua lingua preferita è un buon modo per trasformare XML.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.