XSLT și alternative posibile [închis] (Inginerie software, Xml, Lisp, Linq, Xslt)

wirrbel a intrebat.
a intrebat.

Am aruncat o privire la XSLT pentru transformarea unui fișier XML în altul (HTML etc.). Acum, deși văd că XSLT are avantaje (fiind un instrument standardizat și utilizat), sunt reticent din câteva motive

  • procesoarele XSLT par a fi destul de mari / mari consumatoare de resurse
  • XML este o notație proastă pentru programare și despre asta este vorba în XSLT.

Totuși, nu vreau să trollez XSLT aici, ci doar să subliniez ceea ce nu-mi place la el pentru a vă da o idee despre ceea ce m-aș aștepta de la o alternativă.

Având ceva cunoștințe de Lisp, mă întreb dacă nu cumva există metode mai bune pentru transformări de structuri arborescente bazate pe ceva lisp. Am văzut referințe la DSSSL, din păcate majoritatea link-urilor despre DSSSL sunt moarte, așa că este deja o provocare să văd niște coduri care să-l ilustreze. Mai este DSSSL încă în uz? Îmi amintesc că am instalat odată openjade când am verificat chestii din docbook.

Postarea de pe blogul lui Jeff Atwood pare să sugereze utilizarea lui Ruby în loc de XSLT.

Există vreo modalitate sănătoasă de a face transformări XML similare cu XSLT într-un limbaj de programare non-xml? Aș fi deschis la sugestii cu privire la

  • Biblioteci utile pentru limbajele de scripting care facilitează transformările XML
  • în special (dar nu exclusiv) limbaje de transformare de tip lisp, sau Ruby, etc.

Câteva lucruri pe care le-am găsit până acum:

Comentarii

  • Folosesc HXT și Haskell destul de des, este foarte plăcut –  > Por Daniel Gratzer.
  • În mod corect, nu Jeff Atwood este cel care susține Ruby, ci îl citează pe Martin Fowler, care preferă Ruby. Postarea originală a lui Fowler este aici: martinfowler.com/bliki/MovingAwayFromXslt.html Și a fost scris acum 10 ani, în 2003 – cred că XSLT 2.0 a apărut în 2007 și cu multe îmbunătățiri, iar XPath 2.0 în 2010. –  > Por FrustratedWithFormsDesigner.
5 răspunsuri
Michael Kay

Este dificil să evaluezi tehnologiile atunci când nu ai o experiență profundă cu ele, dar, desigur, exact atunci trebuie să iei decizii, așa că nu există un răspuns simplu la această dilemă.

Menționați două preocupări: performanța și utilizabilitatea. Voi încerca să le abordez pe amândouă mai jos.

În primul rând, performanța. Performanța depinde, desigur, nu numai de limbaj, ci și de implementare și, de asemenea, de expertiza utilizatorilor. Diferitele procesoare XSLT pot varia foarte mult în ceea ce privește performanța, iar același procesor poate varia foarte mult în funcție de modul în care este utilizat (în cazul Saxon, de exemplu, se constată foarte des că persoanele care au probleme de performanță îl utilizează cu DOM, ceea ce reprezintă o combinație proastă, iar performanța poate crește de zece ori dacă se utilizează în schimb modelul nativ de arbore al Saxon). Așadar, primul sfat este să nu luați performanțele după ureche, ci să le măsurați; iar al doilea sfat este să vă asigurați că persoana care face măsurătorile are suficientă experiență pentru a nu face greșeli prostești. Mai ușor de spus decât de făcut.

În mod grosier, puteți separa sarcinile de transformare în două categorii: simple și complexe. În cazul transformărilor simple, cu un procesor XSLT bun, timpul este petrecut în întregime cu analiza și serializarea, iar timpul de procesare XSLT abia dacă intră în discuție. Deoarece orice altă tehnologie va suporta aceleași costuri de parsare și serializare, alegerea tehnologiei de transformare nu va face o mare diferență (cu excepția, poate, a unei codificări de nivel foarte scăzut care utilizează streaming, dar nu mulți oameni își pot permite timpul de programare și competențele necesare pentru a implementa acest lucru). Pentru transformări complexe pe documente mari, încep să apară aceleași probleme ca și în cazul programării SQL: obținerea unei performanțe bune necesită o bună interacțiune între abilitățile și cunoștințele programatorului și capacitățile optimizatorului. Ca și în cazul SQL, este foarte ușor, într-un limbaj de nivel atât de înalt, să scrii câteva instrucțiuni simple care au ca rezultat faptul că procesorul trebuie să facă o cantitate foarte mare de muncă. Dar, la fel ca în cazul SQL, programatorii care știu ce fac se vor descurca mult mai bine decât novicii.

În al doilea rând, ușurința de utilizare. Sintaxa bazată pe XML pentru XSLT este foarte neplăcută pentru mulți oameni la prima întâlnire cu acest limbaj. Dar există motive întemeiate și beneficii reale pentru a proceda astfel: există argumentul „șablonului”, conform căruia o mare parte din cod constă în XML care trebuie scris în documentul rezultat, iar cel mai bun mod de a scrie XML este în XML. Și mai există argumentul „reflecției”; în sistemele complexe mari, este foarte frecvent să se găsească foi de stil care generează foi de stil. Apoi, există argumentul „instrumentelor”; dacă lucrați într-un atelier XML, probabil că dispuneți de o mulțime de instrumente XML, cum ar fi editorii direcționați spre sintaxă, și este bine să puteți utiliza aceleași instrumente pentru a vă gestiona programele și datele. Dezavantajele se dovedesc a fi destul de cosmetice în comparație cu acestea: există numărul de apăsări de taste implicate în editare (ușor de rezolvat cu un instrument de editare bun) și există verbozitatea codului (ceea ce reduce lizibilitatea acestuia). Verbozitatea este mult redusă în XSLT 2.0 odată cu introducerea unor caracteristici precum expresiile regulate și funcțiile foilor de stil: multe foi de stil sunt reduse la jumătate sau la o treime din dimensiune atunci când profită pe deplin de XSLT 2.0.

Menționarea DSSSL mă lasă cu un zâmbet ironic. Nu am folosit niciodată DSSSL, dar poveștile pe care le-am auzit au fost că nu a avut succes deoarece sintaxa sa era obscură și nu avea legătură cu sintaxa datelor (SGML). Folosirea unei sintaxe XML pentru XSLT a fost puternic motivată de experiența cu DSSSL.

Există persoane care iubesc XSLT și persoane care îl urăsc. În mod nesurprinzător, cei care îl folosesc foarte mult tind să se încadreze în prima categorie. Cei cărora nu le place sunt, în general, cei care nu au învățat să „gândească în stilul XSLT”. Ați putea argumenta că un limbaj de programare nu ar trebui să afecteze modul în care gândiți, dar o face: scrierea într-un limbaj bazat pe reguli necesită o mentalitate diferită de scrierea într-un limbaj imperativ. Prima reacție a multor programatori este că se simt mai puțin stăpâni pe situație (descriind problema, mai degrabă decât spunându-i computerului ce să facă pas cu pas). Este foarte asemănătoare cu reacția pe care o vedeai când oamenii au fost introduși pentru prima dată în SQL. În zilele noastre, oamenii învață SQL mai devreme în cariera lor, astfel încât este nevoie de mai puțină reajustare mentală.

În cele din urmă, ar trebui să alegeți o tehnologie pe baza unor criterii obiective și măsurabile, nu pe baza unor reacții de dragoste/ură. Este dificil să faci aceste măsurători. Dar există o mulțime de oameni care folosesc XSLT foarte intensiv și cu succes, așa că nu există nicio îndoială că se poate face.

Comentarii

  • Termenul mai comun pentru „limbaj bazat pe reguli” este un limbaj declarativ. –  > Por Daniel Gratzer.
  • @Michael Kay – Bine spus. Personal, îmi place XSLT și îl folosesc cu C#. În plus, îl folosesc cu XSL-FO pentru a produce documente PDF. XSLT este puternic, foarte puternic, permițându-mi să convertesc rapid cantități mari de date în HTML, XSL-FO, XML sau text. –  > Por PhillyNJ.
Arseni Mourzenko

Fără informații suplimentare despre context, este dificil de răspuns.

Totuși, nu înțeleg de ce nu doriți să folosiți XSLT. Este instrumentul potrivit pentru această sarcină, și unul puternic. Este făcut special pentru a transforma un XML în altul.

Procesoarele XSLT par a fi destul de mari / mari consumatoare de resurse

Aveți date concrete care să susțină acest lucru? Ați implementat soluția folosind XSLT și ați constatat că XSLT este gâtul de îmbulzeală care face imposibilă livrarea produsului, îndeplinind în același timp toate cerințele nefuncționale legate de performanță?

Fără date statistice și profilare, nu puteți afirma în mod rezonabil că o anumită soluție nu va funcționa. Sunt cerințele nefuncționale suficient de rezonabile? Ați prefera să irosiți, să zicem, zece zile de muncă a dezvoltatorilor pentru a câștiga câteva sute de milisecunde prin înlocuirea XSLT cu o altă alternativă? Merită acest lucru?

XML este o notație proastă pentru programare și despre asta este vorba în cazul XSLT.

Deci doriți să transformați un XML în altul, dar nu doriți să folosiți XSLT pentru că „XML este o notație proastă”?

Dacă te deranjează atât de mult faptul că folosești XML ca pe un fel de limbaj de programare, consideră că nu este vorba de programare, ci mai degrabă de o serie de reguli de transformare.

Nici măcar nu trebuie să scrieți XSLT de mână. Există o mulțime de editoare ETL care vă permit să mapărați grafic un XML în altul: nu este nevoie de niciun fel de programare. Unele dintre ele utilizează XSLT ca ieșire.

Comentarii

  • Am întâlnit probleme de resurse cu foi bazate pe XSLT, acestea au fost create cu un instrument grafic, dar acesta a încetat să mai funcționeze cu fișiere mai mari. –  > Por wirrbel.
  • atunci probabil că există probleme cu XSLT file nu XSLT Transformations ei înșiși –  > Por Malachi.
  • Acum nu condamn XML, de fapt, cred că este adecvat pentru reprezentarea datelor (în special pentru marcare). Ca „limbaj de programare” – iar XSLT este un limbaj de programare specific domeniului – este incomod. <xsl:whatever > Etichete, metalimbaje (cum ar fi xpath, notația $ etc.) în atributele de interogare, tot ceea ce nu este mapat în XML este pus între ghilimele de atribut. Pentru o impresie a unei reprezentări s-expresii XML: blog.getprismatic.com/blog/2013/1/22/… în astfel de departe se poate ca XML și și proglang să funcționeze aparent –  > Por wirrbel.
Michael Shaw

Dacă folosiți XSLT pentru a genera XML pe baza XSLT-ului brut și a unor parametri pe care îi transmiteți motorului XSLT, atunci utilizarea unei abordări de tip templating XML este mult mai ușor de înțeles și de întreținut.

Am participat la un proiect în care Moustache a fost folosit pentru a înlocui XSLT, iar rezultatul a fost fișiere XML de bază mult mai simple, pe care toată lumea le putea edita și ajusta, în loc ca acea muncă de proiect să fie încredințată unuia sau două suflete curajoase, care stăteau în liniște totală, cu perle de sudoare curgând…

Abordarea bazată pe șabloane nu este adecvată atunci când XML-ul de bază este, de asemenea, o informație validă în sine, iar XSLT este utilizat pentru a oferi o reprezentare alternativă sau un extras din XML-ul sursă.

Comentarii

  • Vreți să explicați mai multe despre ce face și de ce o recomandați ca răspuns la întrebarea adresată? „Link-only answers” nu sunt tocmai binevenite la Stack Exchange –  > Por gnat.
  • răspuns revizuit în concordanță cu comentariile dumneavoastră –  > Por Michael Shaw.
Malachi

XML nu este un limbaj de programare

XML este o modalitate de a transfera/transporta date.
O instrucțiune XSLT utilizează Xpath pentru a interoga datele într-un mod specific și a le introduce într-un alt obiect/document de transport de date.

ȘI/SAU

XSLT poate transforma XML-ul în HTML, care este un alt mod de a afișa/transporta datele conținute într-un document XML.

dacă doriți să modificați XML sau să creați un document XML, atunci puteți utiliza orice număr de limbaje: C#, VB, Ruby, etc.

de obicei, atunci când folosiți un fișier XSLT pentru a transforma un document XML, aveți încă documentul XML original; de fapt, nu modificați documentul original, ci creați unul nou.

Comentarii

  • Wikipedia spune: „XSLT este un limbaj Turing-complet, ceea ce înseamnă că poate specifica orice calcul care poate fi efectuat de un computer.”. Nu am spus niciodată că XML este un limbaj de programare în sine. –  > Por wirrbel.
  • ați spus că „XML este o notație proastă pentru programare”. În limbajele de programare pe care le-am folosit, puteți extrage date din fișiere XML destul de ușor. XSLT câștigă teren în ceea ce privește capacitatea de a face o mulțime de calcule și de a trimite datele respective către un alt obiect/document de transport de date. este ca SQL pentru SQL Server, care poate face o mulțime de lucruri, dar este în principal back-end, nu front-end. SQL, la fel ca XSLT, interoghează datele într-un anumit mod, dar nu doriți niciodată să oferiți rezultatele interogării sub formă de raport, ci doriți să trimiteți informațiile către un creator de rapoarte.  > Por Malachi.
  • XSLT nu interoghează datele, ci XPATH face interogarea. XSLT nu este un limbaj declarativ care definește instrucțiuni asupra xml-ului analizat? –  > Por PhillyNJ.
  • XSLT definește reguli de transformare bazate pe modele pentru care poate utiliza Xpath. Adică puteți avea construcții de programare de nivel înalt, cum ar fi xsl:for-each xsl:apply-templates, xsl:if xsl:call-template xsl:value-of pentru a defini regulile de transformare. –  > Por wirrbel.
  • @PhilVallone Sunt de acord. Am greșit acolo. wirrbel, nu am de gând să mă cert cu tine în legătură cu ceea ce este și ce nu este XSLT/XSL, dacă vrei să transformi un document XML într-un alt document XML, vei dori să folosești XSLT/XSL. –  > Por Malachi.
Michael Shopsin

Am lucrat la mai multe sisteme de procesare XML care combină bibliotecile XSLT cu Java sau C++ pentru părțile la care XSLT nu este la fel de bun. Există biblioteci care obțin performanțe XSLT foarte bune chiar și pe fișiere XML de 20 MB, însă XSLT are unele limitări în ceea ce privește contextul, variabilele și modelele de șiruri de caractere foarte complexe. Fiecare sistem la care am lucrat a avut câteva lucruri realizate în Java/C++, deoarece contextul era important sau o expresie regex complexă a ajutat. Concluzia mea este că XSLT plus câteva coduri suplimentare în limbajul ales de dumneavoastră este o modalitate bună de a transforma XML.

Tags:, , ,