XSLT e possibili alternative [chiuso]

13

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 piuttosto enormi / affamati di risorse
  • XML è una brutta notazione per la programmazione e questo è tutto ciò che riguarda XSLT.

Non voglio trollare XSLT qui, ma voglio solo far notare ciò che non mi piace per darti un'idea di cosa mi aspetterei da un'alternativa.

Avendo qualche background Lisp mi chiedo se ci siano modi migliori per le trasformazioni della struttura ad albero basate su qualche lisp. Ho visto riferimenti a DSSSL, purtroppo molti link su DSSSL sono morti quindi è già difficile vedere un codice che lo illustri. DSSSL è ancora in uso? Ricordo che avevo installato openjade una volta durante il check-out dei documenti del docbook.

Il blog di Jeff Atwood sembra suggerire Ruby invece di XSLT.

Esistono modi sane per eseguire trasformazioni XML simili a XSLT in un linguaggio di programmazione non xml? Sarei aperto per l'inserimento su

  • Librerie utili per linguaggi di scripting che facilitano le trasformazioni XML
  • in particolare (ma non esclusivamente) i linguaggi di trasformazione simili al Lisp, o Ruby, ecc.

Alcune cose che ho trovato finora:

  • Un paio di posti sul web hanno indicato Linq come possibile alternativa. Abbastanza generalmente ho qualsiasi tipo di classificazione, anche da quelli che hanno avuto la migliore esperienza XSLT.
  • Per lo schema link e link
posta wirrbel 10.09.2013 - 18:53
fonte

5 risposte

17

È 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 questo dilemma.

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

In primo luogo, le prestazioni. Le prestazioni dipendono ovviamente non solo dalla lingua, ma anche dall'implementazione e anche dalle competenze degli utenti. Diversi processori XSLT possono variare ampiamente nelle prestazioni, e lo stesso processore può variare ampiamente a seconda di come viene utilizzato (con Saxon, ad esempio, le persone con problemi di prestazioni si trovano spesso ad usarlo con DOM, che è una combinazione scarsa e le prestazioni possono aumentare di dieci volte se si utilizza invece il modello di albero nativo di Saxon). Quindi il primo consiglio è di non prendere prestazioni per sentito dire, misurarlo; e il secondo consiglio è di assicurarsi che la persona che fa le misurazioni abbia abbastanza esperienza da non commettere errori stupidi. Più facile a dirsi che a farsi.

Rudemente, puoi separare i lavori di trasformazione in due categorie: semplice e complessa. Per le trasformazioni semplici, con un buon processore XSLT viene speso il tempo di analisi e serializzazione e il tempo di elaborazione dell'XSLT difficilmente entra in scena. Poiché qualsiasi altra tecnologia sta per sostenere gli stessi costi di analisi e serializzazione, la scelta della tecnologia di trasformazione non farà una grande differenza (tranne forse molto 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, si iniziano a ottenere gli stessi problemi della programmazione SQL: il raggiungimento di buone prestazioni richiede una buona interazione tra le competenze e le conoscenze del programmatore e le funzionalità dell'ottimizzatore. Come con SQL, è molto facile in un linguaggio di così alto livello scrivere poche semplici istruzioni che comportano un notevole lavoro da parte del processore. Ma anche come con SQL, i programmatori che sanno quello che stanno facendo faranno molto meglio dei novizi.

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 "modello", che molto del codice è costituito da XML da scrivere nel documento risultato, e il modo migliore per scrivere XML è in XML. E c'è l'argomento "riflessione"; in sistemi di grandi dimensioni, è molto comune trovare fogli di stile che generano fogli di stile. Poi c'è l'argomento "strumenti"; se sei in un negozio XML, probabilmente hai molti strumenti XML come gli editor diretti alla sintassi ed è bello poter usare gli stessi strumenti per gestire i tuoi programmi e i tuoi dati. Gli svantaggi risultano alquanto estetici rispetto al confronto: il numero di sequenze di tasti coinvolte nell'editing (facilmente risolvibile con un buon strumento di modifica) e la prolissità del codice (che ne riduce la leggibilità). La verbosità è enormemente ridotta in XSLT 2.0 con l'introduzione di funzionalità quali espressioni regolari e funzioni del foglio di stile: molti fogli di stile sono ridotti a metà o un terzo in termini di dimensioni quando sfruttano pienamente 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 erano che non era adatto perché la sua sintassi era arcana e non correlata alla sintassi dei dati (SGML). L'uso di una sintassi XML per XSLT era strongmente motivato dall'esperienza con DSSSL.

Ci sono persone che amano l'XSLT e ci sono persone che lo odiano. Non sorprendentemente, quelli che lo usano molto tendono a cadere nella prima categoria. Quelli a cui non piacciono di solito sono quelli che non hanno imparato a "pensare al 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 si vedeva quando le persone venivano introdotte per la prima volta in SQL. In questi giorni, le persone imparano SQL in precedenza nella loro carriera, quindi è necessario un minore adeguamento mentale.

In definitiva, dovresti scegliere una tecnologia basata su criteri oggettivi misurabili, non su reazioni di amore / odio. È difficile fare quelle misurazioni. Ma ci sono molte persone che usano XSLT molto intensamente e con molto successo, quindi non c'è dubbio che possa essere fatto.

    
risposta data 10.09.2013 - 22:16
fonte
4

Senza ulteriori informazioni sul contesto, è difficile rispondere.

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

XSLT processors seem to be quite huge / resource hungry

Hai dati complessi per supportarlo? Hai implementato la soluzione utilizzando XSLT e hai scoperto che XSLT è il collo di bottiglia che rende impossibile la consegna del prodotto mentre soddisfa tutti i requisiti non funzionali relativi alle prestazioni?

Senza dati statistici e profili, 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 centinaio di millisecondi sostituendo XSLT con un'altra alternativa? Ne vale la pena?

XML is a bad notation for programming and thats what XSLT is all about.

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

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

Non hai nemmeno bisogno di scrivere XSLT a mano. Ci sono un sacco di editor ETL che ti permettono di mappare graficamente un XML in antother: nessuna programmazione richiesta di sorta. Alcuni di loro usano XSLT come output.

    
risposta data 10.09.2013 - 20:09
fonte
1

Se utilizzi XSLT per generare XML in base all'XSLT non elaborato e alcuni parametri che stai trasmettendo al motore XSLT, l'utilizzo di un approccio XML per i modelli è molto più semplice da comprendere e mantenere.

Sono stato in un progetto in cui Moustache è stato utilizzato per sostituire XSLT e il risultato è stato molto più semplici file XML di base che tutti potevano modificare e modificare, piuttosto che il lavoro di progetto passato a uno o due anime coraggiosi, che si sedevano in totale silenzio con gocce di sudore che si riversavano fuori ...

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

    
risposta data 17.09.2013 - 18:00
fonte
0

XML non è un linguaggio di programmazione

XML è un modo per trasferire / trasportare dati.
l'istruzione XSLT utilizza Xpath per interrogare i dati in un modo specifico e inserirli 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 di creare un documento XML, puoi utilizzare qualsiasi numero di lingue: C #, VB, Ruby, Etc.

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

    
risposta data 10.09.2013 - 20:21
fonte
0

Ho lavorato su più sistemi di elaborazione XML che combinano librerie XSLT con Java o C ++ per le parti in cui XSLT non è così bravo. Esistono 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 molto complessi. Ogni sistema su cui ho lavorato ha fatto alcune cose in Java / C ++ perché il contesto era importante o qualche espressione regex complessa aiutata. Il mio takeaway è che XSLT più un codice aggiuntivo nella tua lingua preferita è un buon modo per trasformare XML.

    
risposta data 17.09.2013 - 17:24
fonte

Leggi altre domande sui tag