¿Vale la pena XSLT?[cerrado]

https://stackoverflow.com/questions/78716

xml
xslt

09-06-2019
|

Pregunta

Hace un tiempo, comencé un proyecto en el que diseñé un esquema XML similar a HTML para que los autores pudieran escribir su contenido (material del curso educativo) en un formato simplificado que luego se transformaría a HTML a través de XSLT.Jugué (luché) con él por un tiempo y lo llegué a un nivel muy básico, pero luego me molestaron demasiado las limitaciones que estaba encontrando (que bien pueden haber sido limitaciones de mi conocimiento) y cuando leí un blog que sugería abandonarlo. XSLT y simplemente escriba su propio analizador XML a cualquier cosa en el idioma que elija. Me lancé a eso con entusiasmo y funcionó de manera brillante.

Todavía estoy trabajando en ello hasta el día de hoy (De hecho, se supone que debo estar trabajando en ello ahora mismo, en lugar de jugar en SO.), y veo cada vez más cosas que me hacen pensar que la decisión de deshacerme de XSLT fue buena.

Sé que XSLT tiene su lugar, ya que es un estándar aceptado y que si todos escriben sus propios intérpretes, el 90% de ellos terminarán en El DailyWTF.Pero dado que es un lenguaje de estilo funcional en lugar del estilo procedimental con el que la mayoría de los programadores están familiarizados, para alguien que se embarca en un proyecto como el mío, ¿Recomendarías que siguieran el camino que yo hice o que siguieran con XSLT??

Solución

Ventajas de XSLT:

Específico del dominio para XML, por lo que, por ejemplo, no es necesario citar XML literal en la salida.
Admite XPath/XQuery, que puede ser una buena forma de consultar DOM, de la misma manera que las expresiones regulares pueden ser una buena forma de consultar cadenas.
Idioma funcional.

Desventajas de XSLT:

Puede ser obscenamente detallado: no es necesario citar XML literal, lo que efectivamente significa que sí debe citar el código.Y no de una manera bonita.Pero claro, no es mucho peor que el SSI típico.
No hace ciertas cosas que la mayoría de los programadores dan por sentado.Por ejemplo, la manipulación de cuerdas puede ser una tarea ardua.Esto puede llevar a "momentos desafortunados" cuando los principiantes diseñan código y luego buscan frenéticamente en la web sugerencias sobre cómo implementar funciones que asumieron que simplemente estarían ahí y no se dieron tiempo para escribir.
Idioma funcional.

Por cierto, una forma de obtener un comportamiento procedimental es encadenar múltiples transformaciones.Después de cada paso, tienes un nuevo DOM en el que trabajar que refleja los cambios en ese paso.Algunos procesadores XSL tienen extensiones para hacer esto de manera efectiva en una sola transformación, pero olvido los detalles.

Entonces, si su código es principalmente de salida y no tiene mucha lógica, XSLT puede ser una forma muy clara de expresarlo.Si hay mucha lógica, pero principalmente formularios integrados en XSLT (seleccione todos los elementos que parezcan bla, y para cada uno de ellos salga bla), es probable que sea un entorno bastante amigable.Si te apetece pensar en XML en todo momento, prueba XSLT 2.

De lo contrario, diría que si su lenguaje de programación favorito tiene una buena implementación DOM que admita XPath y le permita crear documentos de una manera útil, entonces el uso de XSLT tiene pocos beneficios.Los enlaces a libxml2 y gdome2 deberían funcionar bien, y no es ninguna vergüenza apegarse a lenguajes de propósito general que conoces bien.

Los analizadores XML locales suelen estar incompletos (en cuyo caso algún día dejarás de funcionar) o no son mucho más pequeños que algo que podrías haber conseguido en el mercado (en cuyo caso probablemente estés perdiendo el tiempo), y dan ofrece numerosas oportunidades para introducir graves problemas de seguridad relacionados con entradas maliciosas.No escriba uno a menos que sepa exactamente lo que gana al hacerlo.Lo que no quiere decir que no pueda escribir un analizador para algo más simple que XML como formato de entrada, si no necesita todo lo que ofrece XML.

Otros consejos

¡Cuánta negatividad!

He estado usando XSLT durante algunos años y realmente me encanta.La cosa clave de la que debes darte cuenta es que No es un lenguaje de programación, es un lenguaje de plantillas. (y en este sentido lo encuentro indescriptiblemente superior a asp.net /spit).

XML es el formato de datos de facto del desarrollo web actual, ya sean archivos de configuración, datos sin procesar o representación en memoria.XSLT y XPath le brindan una enormemente forma poderosa y muy eficiente de transformar esos datos en cualquier formato de salida que desee, brindándole instantáneamente ese aspecto MVC de separar la presentación de los datos.

Luego están las habilidades de utilidad:eliminar espacios de nombres, reconocer definiciones de esquemas dispares, fusionar documentos.

Él debe Sería mejor trabajar con XSLT que desarrollar sus propios métodos internos.Al menos XSLT es un estándar y algo para lo que podría contratar, y si alguna vez es realmente un problema para su equipo, su naturaleza le permitirá mantener a la mayor parte de su equipo trabajando solo con XML.

Un caso de uso del mundo real:Acabo de escribir una aplicación que maneja documentos XML en memoria en todo el sistema y los transforma a JSON, HTML o XML según lo solicite el usuario final.Recibí una solicitud bastante aleatoria para proporcionar datos como Excel.Un antiguo colega había hecho algo similar programáticamente, pero requería un módulo de algunos archivos de clase y que el servidor tuviera instalado MS Office.Resulta que Excel tiene un XSD:Nueva funcionalidad con impacto mínimo en el código base en 3 horas.

Personalmente, creo que es una de las cosas más limpias que he encontrado en mi carrera, y creo que todos sus problemas aparentes (depuración, manipulación de cadenas, estructuras de programación) se deben a una comprensión errónea de la herramienta.

Obviamente, creo firmemente que "vale la pena".

Tengo que admitir un sesgo aquí porque me gano la vida enseñando XSLT.Pero podría valer la pena cubrir las áreas en las que veo trabajar a mis alumnos.Generalmente se dividen en tres grupos:editorial, banca y web.

Muchas de las respuestas hasta ahora podrían resumirse en "no sirve para crear sitios web" o "no se parece en nada al lenguaje X".Mucha gente de tecnología sigue sus carreras sin exposición a lenguajes funcionales/declarativos.Cuando estoy enseñando, las personas experimentadas en Java/VB/C/etc son las que tienen problemas con el lenguaje (las variables son variables en el sentido de álgebra, no de programación de procedimientos, por ejemplo).Esas son muchas de las personas que responden aquí: nunca me he llevado bien con Java, pero no me voy a molestar en criticar el lenguaje por eso.

En muchas circunstancias, es una herramienta inapropiada para crear sitios web; un lenguaje de programación de propósito general puede ser mejor.A menudo necesito tomar documentos XML muy grandes y presentarlos en la web;XSLT hace que eso sea trivial.Los estudiantes que veo en este espacio tienden a procesar conjuntos de datos y presentarlos en la web.Ciertamente, XSLT no es la única herramienta aplicable en este espacio.Sin embargo, muchos de ellos utilizan DOM para hacer esto y XSLT es ciertamente menos doloroso.

Los estudiantes de banca que veo usan una caja DataPower en general.Este es un dispositivo XML y se utiliza para ubicarse entre servicios que "hablan" diferentes dialectos XML.La transformación de un lenguaje XML a otro es casi trivial en XSLT y el número de estudiantes que asisten a mis cursos sobre este tema está aumentando.

El grupo final de estudiantes que veo provienen del ámbito editorial (como yo).Estas personas tienden a tener inmensos documentos en XML (créanme, la industria editorial se está adentrando mucho en XML; la publicación técnica ha existido durante años y la publicación comercial está llegando a ese punto ahora).Estos documentos deben procesarse (aquí me viene a la mente DocBook to ePub).

Alguien comentó anteriormente que los guiones tienden a tener menos de 60 líneas o se vuelven difíciles de manejar.Si se vuelve difícil de manejar, lo más probable es que el programador no haya captado realmente la idea: XSLT tiene una mentalidad muy diferente a la de muchos otros lenguajes.Si no tienes la mentalidad, no funcionará.

Ciertamente no es un idioma en extinción (la cantidad de trabajo que recibo me lo dice).En este momento, está un poco "atascado" hasta que Microsoft termine su (muy tardía) implementación de XSLT 2.Pero todavía está ahí y parece estar fortaleciéndose desde mi punto de vista.

Usamos XSLT ampliamente para cosas como documentación y para hacer que algunas configuraciones complejas sean útiles para el usuario.

Para la documentación utilizamos mucho DocBook, que es un formato basado en XML.Esto nos permite almacenar y gestionar nuestra documentación con todo nuestro código fuente, ya que los archivos son texto plano.Con XSLT, podemos crear fácilmente nuestros propios formatos de documentación, lo que nos permite generar automáticamente el contenido de forma genérica y hacerlo más legible.Por ejemplo, cuando publicamos notas de la versión, podemos crear XML que se vea así:

<ReleaseNotes>
    <FixedBugs>
        <Bug id="123" component="Admin">Error when clicking the Foo button</Bug>
        <Bug id="125" component="Core">Crash at startup when configuration is missing</Bug>
        <Bug id="127" component="Admin">Error when clicking the Bar button</Bug>
    </FixedBugs>
</ReleaseNotes>

Y luego, usando XSLT (que transforma lo anterior en DocBook), terminamos con buenas notas de la versión (generalmente PDF o HTML) donde las ID de errores se vinculan automáticamente a nuestro rastreador de errores, los errores se agrupan por componente y el formato de todo es perfectamente consistente. .Y el XML anterior se puede generar automáticamente consultando nuestro rastreador de errores sobre qué ha cambiado entre versiones.

El otro lugar donde encontramos útil XSLT es en nuestro producto principal.A veces, cuando interactuamos con sistemas de terceros, necesitamos de alguna manera procesar datos en una página HTML compleja.Analizar HTML es feo, por lo que alimentamos los datos a través de algo como EtiquetaSopa (que genera eventos SAX XML adecuados, esencialmente permitiéndonos tratar el HTML como si fuera XML escrito correctamente) y luego podemos ejecutar algo de XSLT en él, para convertir los datos en un formato "estable conocido" con el que realmente podamos trabajar. .Al separar esa transformación en un archivo XSLT, eso significa que si el formato HTML cambia, no es necesario actualizar la aplicación en sí, sino que el usuario final puede simplemente editar el archivo XSLT por sí mismo, o podemos enviarlo por correo electrónico. envíeles un archivo XSLT actualizado sin necesidad de actualizar todo el sistema.

Yo diría que para proyectos web, existen mejores formas de manejar la vista que XSLT hoy en día, pero como tecnología definitivamente hay usos para XSLT.No es el lenguaje más fácil de usar del mundo, pero definitivamente no está muerto y, desde mi punto de vista, todavía tiene muchos buenos usos.

XSLT es un ejemplo de programación declarativa idioma.

Otros ejemplos de lenguajes de programación declarativos incluyen expresiones regulares, Prolog y SQL.Todos ellos son muy expresivos y compactos y, por lo general, muy bien diseñados y potentes para la tarea para la que están diseñados.

Sin embargo, los desarrolladores de software generalmente odian estos lenguajes porque son tan diferentes de los lenguajes procedimentales o OO más convencionales que son difíciles de aprender y depurar.Su naturaleza compacta generalmente hace que sea muy fácil causar muchos daños sin darse cuenta.

Entonces, si bien XSLT es un mecanismo eficiente para fusionar datos en una presentación, falla en el departamento de facilidad de uso.Creo que es por eso que realmente no se ha popularizado.

Recuerdo todo el revuelo en torno a XSLT cuando se lanzó el estándar.Toda la emoción por poder crear una interfaz de usuario HTML completa con una transformación "simple".

Seamos realistas: es difícil de usar, casi imposible de depurar y, a menudo, insoportablemente lento.El resultado final es casi siempre peculiar y menos que ideal.

Prefiero morderme la pierna que usar un XSLT mientras haya mejores formas de hacer las cosas.Aún así tiene sus lugares, es bueno para tareas de transformación simples.

He usado XSLT (y también XQuery) ampliamente para varias cosas: para generar código C++ como parte del proceso de compilación, para producir documentación a partir de comentarios de documentos y dentro de una aplicación que tenía que trabajar mucho con XML en general y XHTML en particular. .El generador de código en particular tenía más de 10.000 líneas de código XSLT 2.0 distribuidas en aproximadamente una docena de archivos separados (hizo muchas cosas: encabezados para clientes, servidores proxy/stubs remotos, contenedores COM, contenedores .NET, ORM, por nombrar algunos).Lo heredé de otro chico que realmente no entendía bien el idioma y, en consecuencia, las partes más antiguas eran un desastre.Sin embargo, el material más nuevo que escribimos se mantuvo en su mayoría sano y legible, y no recuerdo ningún problema particular para lograrlo.Ciertamente no fue más difícil que hacerlo para C++.

Hablando de versiones, lidiar con XSLT 2.0 definitivamente te ayuda a mantenerte cuerdo, pero 1.0 aún está bien para transformaciones más simples.En su nicho, es una herramienta extremadamente útil y la productividad que se obtiene de ciertas características específicas del dominio (lo más importante, el envío dinámico a través de la coincidencia de plantillas) es difícil de igualar.A pesar de la palabrería percibida de la sintaxis basada en XML de XSLT, lo mismo en LINQ to XML (incluso en VB con literales XML) solía ser varias veces más largo.Sin embargo, muy a menudo recibe críticas inmerecidas debido al uso innecesario de XML en algunos casos.

En resumen:Es una herramienta increíblemente útil en la caja de herramientas, pero es muy especializada, por lo que es buena siempre que la uses correctamente y para el propósito previsto.Realmente desearía que hubiera una implementación .NET nativa adecuada de XSLT 2.0.

Utilizo XSLT (a falta de una alternativa mejor), pero no para presentación, solo para transformación:

Escribo transformaciones XSLT breves para realizar ediciones masivas en nuestros archivos maven pom.xml.
He escrito una serie de transformaciones para generar esquemas XML desde XMI (diagrama UML).Funcionó por un tiempo, pero finalmente se volvió demasiado complejo y tuvimos que sacarlo detrás del granero.
He usado transformaciones para refactorizar esquemas XML.
He solucionado algunas limitaciones en XSLT usándolo para generar un XSLT para hacer el trabajo real.(¿Alguna vez ha intentado escribir un XSLT que produzca una salida utilizando espacios de nombres que no se conocen hasta el tiempo de ejecución?)

Sigo volviendo a él porque hace un mejor trabajo ida y vuelta con el XML que está procesando que otros enfoques que he probado, que me han parecido innecesariamente con pérdidas o simplemente no entienden XML.XSLT es desagradable, pero encuentro que usar Oxígeno lo hace soportable.

Dicho esto, estoy investigando usando Clojure (un ceceo) para realizar transformaciones de XML, pero aún no he llegado lo suficientemente lejos como para saber si ese enfoque me traerá beneficios.

Personalmente utilicé XSLT en un contexto totalmente diferente.El juego de computadora en el que estaba trabajando en ese momento usaba toneladas de páginas de interfaz de usuario definidas mediante XML.Durante una refactorización importante poco después del lanzamiento, queríamos cambiar la estructura de estos documentos XML.Hicimos que el formato de entrada del juego siguiera una estructura mucho mejor y consciente del esquema.

XSLT parecía la elección perfecta para esta traducción del formato antiguo -> Nuevo formato.En dos semanas tuve una conversión funcional de lo antiguo a lo nuevo para nuestros cientos de páginas.También pude usarlo para extraer mucha información sobre el diseño de nuestras páginas de interfaz de usuario.Creé listas de qué componentes estaban integrados con relativa facilidad y luego usé XSLT para escribir en nuestras definiciones de esquema.

Además, al tener experiencia en C++, era un lenguaje muy divertido e interesante de dominar.

Creo que como herramienta para traducir XML de un formato a otro es fantástica.Sin embargo, no es la única forma de definir un algoritmo que toma XML como entrada y salida. Algo.Si su algoritmo es lo suficientemente complejo, el hecho de que la entrada sea XML se vuelve irrelevante para su elección de herramienta, es decir, utilice la suya propia en C++/Python/lo que sea.

Específicamente para su ejemplo, me imagino que la mejor idea sería crear su propia conversión XML->XML que siga su lógica empresarial.A continuación, escriba un traductor XSLT que sepa sobre formato y no haga nada inteligente.Podría ser un buen término medio, pero depende totalmente de lo que estés haciendo.Tener un traductor XSLT en la salida facilita la creación de formatos de salida alternativos: imprimibles, para móviles, etc.

Sí, lo uso mucho.Al usar diferentes archivos xslt, puedo usar la misma fuente XML para crear múltiples archivos HTML (X) políglotas (que presentan los mismos datos de diferentes maneras), una fuente RSS, una fuente Atom, un archivo descriptor RDF y un fragmento de un mapa del sitio. .

No es una panacea.Hay cosas que hace bien y cosas que no hace bien y, como todos los demás aspectos de la programación, se trata de utilizar la herramienta adecuada para el trabajo correcto.Es una herramienta que vale la pena tener en su caja de herramientas, pero debe usarse sólo cuando sea apropiado.

Definitivamente recomendaría aguantar.Especialmente si está utilizando Visual Studio, que tiene herramientas integradas de edición, visualización y depuración para XSLT.

Sí, es doloroso mientras aprendes, pero la mayor parte del dolor tiene que ver con la familiaridad.El dolor disminuye a medida que aprendes el idioma.

W3schools tiene dos artículos que son de especial valor:http://www.w3schools.com/xpath/xpath_functions.asp http://www.w3schools.com/xsl/xsl_functions.asp

He descubierto que es bastante difícil trabajar con XSLT.

He tenido experiencia trabajando en un sistema algo similar al que usted describe.Mi empresa notó que los datos que estábamos devolviendo desde "el nivel medio" estaban en XML y que las páginas debían representarse en HTML, que bien podría ser XHTML, además habían oído que XSL era un estándar para transformar entre XML. formatos.Entonces, los "arquitectos" (me refiero a personas que piensan profundamente en el diseño pero aparentemente nunca codifican) decidieron que nuestro nivel frontal se implementaría escribiendo scripts XSLT que transformaban los datos en XHTML para su visualización.

La elección resultó desastrosa.Resulta que escribir XSLT es complicado.Por eso todas nuestras páginas eran difíciles de escribir y mantener.Habría sido mucho mejor haber usado JSP (esto fue en Java) o algún enfoque similar que usara un tipo de marcado (corchetes angulares) para el formato de salida (el HTML) y otro tipo de marcado (como <%... %>) para los metadatos.Lo más confuso de XSLT es que está escrito en XML y se traduce de XML a XML...Es bastante difícil mantener los 3 documentos XML diferentes en la mente.

Tu situación es ligeramente diferente:en lugar de crear cada página en XSLT como lo hice yo, solo necesita escribir UN bit de código en XSLT (el código para convertir de plantillas a mostrar).Pero parece que es posible que te hayas encontrado con el mismo tipo de dificultad que yo.Yo diría que intentar interpretar un DSL (lenguaje específico de dominio) basado en XML simple como lo está haciendo NO es uno de los puntos fuertes de XSLT.(Aunque PUEDE hacer el trabajo...después de todo, ¡ES Turing completo!)

Sin embargo, si lo que tuvieras fuera más simple:tiene datos en un formato XML y desea realizar modificaciones simples en ellos, no un DSL de descripción de página completa, sino algunas modificaciones sencillas y directas, entonces XSLT es una excelente herramienta para ese propósito.Su naturaleza declarativa (no procesal) es en realidad una ventaja para ese propósito.

--Michael Chermside

Es difícil trabajar con XSLT, pero una vez que lo domine, tendrá una comprensión muy profunda del DOM y el esquema.Si también utiliza XPath, entonces estará en camino de aprender programación funcional y esto lo expondrá a nuevas técnicas y formas de resolver problemas.En algunos casos, las transformaciones sucesivas son más poderosas que las soluciones procesales.

Utilizo XSLT ampliamente, para una interfaz de usuario de estilo MVC personalizada.El modelo se "serializa" a xml (no mediante serialización xml) y luego se convierte a html mediante xslt.La ventaja sobre ASP.NET radica en la integración natural con XPath y los requisitos de formato más rigurosos (es mucho más fácil razonar sobre la estructura del documento en xslt que en la mayoría de los otros lenguajes).

Desafortunadamente, el lenguaje contiene varias limitaciones (por ejemplo, la capacidad de transformar el resultado de otra transformación), lo que significa que en ocasiones resulta frustrante trabajar con él.

Sin embargo, la separación de preocupaciones fácilmente lograble y fuertemente impuesta que otorga no es algo que veo que otra tecnología proporcione en este momento, por lo que para las transformaciones de documentos sigue siendo algo que recomendaría.

Utilicé XML, XSD y XSLT en un proyecto de integración entre sistemas de bases de datos muy diferentes en algún momento de 2004.Tuve que aprender XSD y XSLT desde cero pero no fue difícil.Lo mejor de estas herramientas fue que me permitieron escribir código C++ independiente de los datos, confiando en XSD y XSLT para validar/verificar y luego transformar los documentos XML.Cambie el formato de datos, cambie los documentos XSD y XSLT, no el código C++ que emplea las bibliotecas Xerces.

Por interés:el XSD principal era de 150 KB y el tamaño promedio del XSLT era <5 KB IIRC.

El otro gran beneficio es que el XSD es un documento de especificaciones en el que se basa el XSLT.Los dos trabajan en armonía.Y las especificaciones son raras en el desarrollo de software hoy en día.

Aunque no tuve demasiados problemas para aprender la naturaleza declarativa XSD y XSLT, descubrí que otros programadores de C/C++ tuvieron grandes problemas para adaptarse a la forma declarativa.Cuando vieron que eso era todo, ¡ah procesal murmuraron, ahora que entiendo!¡Y procedieron (¿juego de palabras?) a escribir XSLT procesal.La cuestión es que debes aprender XPath y comprender los ejes de XML.Me recuerda a los programadores de C de antaño que se adaptaban al empleo de OO cuando escribían C++.

Utilicé estas herramientas porque me permitieron escribir una pequeña base de código C++ que estaba aislada de todas las modificaciones de la estructura de datos, excepto las más fundamentales, y estas últimas eran cambios en la estructura de la base de datos.Aunque prefiero C++ a cualquier otro lenguaje, usaré lo que considero útil para beneficiar la viabilidad a largo plazo de un proyecto de software.

Solía pensar que XSLT era una gran idea.lo digo en serio es Una gran idea.

Donde falla es la ejecución.

El problema que descubrí con el tiempo fue que los lenguajes de programación en XML son simplemente una mala idea.Hace que todo sea impenetrable.Específicamente, creo que XSLT es muy difícil de aprender, codificar y comprender.El XML además de los aspectos funcionales hace que todo sea demasiado confuso.He intentado aprenderlo unas 5 veces en mi carrera y simplemente no funciona.

Bien, podrías "elaborarlo", creo que ese fue en parte el objetivo de su diseño, pero ese es el segundo fallo:todas las herramientas XSLT del mercado son, simplemente…¡tonterías!

El especificación XSLT define XSLT como "un lenguaje para transformar documentos XML en otros documentos XML".Si está intentando hacer algo que no sea el procesamiento de datos más básico dentro de XSLT, probablemente haya mejores soluciones.

También vale la pena señalar que las capacidades de procesamiento de datos de XSLT se pueden ampliar en .NET utilizando funciones de extensión personalizadas:

Mantengo un sistema de documentación en línea para mi empresa.Los escritores crean la documentación en SGML (un lenguaje similar a xml).Luego, el SGML se combina con XSLT y se transforma en HTML.

Esto nos permite realizar cambios fácilmente en el diseño de la documentación sin necesidad de codificar.Es sólo cuestión de cambiar el XSLT.

Esto funciona bien para nosotros.En nuestro caso, es un documento de solo lectura.El usuario no interactúa con la documentación.

Además, al utilizar XSLT, está trabajando más cerca del dominio de su problema (HTML).Siempre considero que es una buena idea.

Por último, si su sistema actual FUNCIONA, déjelo en paz.Nunca sugeriría desechar su código existente.Si comenzara desde cero, usaría XSLT, pero en tu caso, usaría lo que tienes.

Todo se reduce a para qué lo necesitas.Su principal fortaleza es la fácil mantenibilidad de la transformación, y escribir su propio analizador generalmente lo elimina.Dicho esto, a veces un sistema es pequeño y simple y realmente no necesita una solución "elegante".Siempre que su generador basado en código sea reemplazable sin tener que cambiar otro código, no es gran cosa.

En cuanto a la fealdad de XSL, sí, es fea.Sí, lleva un tiempo acostumbrarse.Pero una vez que lo dominas (en mi opinión, no debería tomar mucho tiempo), en realidad todo es viento en popa.Según mi experiencia, las transformaciones compiladas se ejecutan bastante rápido y ciertamente puedes depurarlas.

Sigo creyendo que XSLT puede ser útil, pero es un lenguaje feo y puede generar un desastre terriblemente ilegible e imposible de mantener.En parte porque XML no es lo suficientemente legible para los humanos como para constituir un "lenguaje" y en parte porque XSLT está atrapado en algún punto entre ser declarativo y procesal.Dicho esto, y creo que se puede hacer una comparación con expresiones regulares, tiene sus usos cuando se trata de problemas simples y bien definidos.

Usar el enfoque alternativo y analizar XML en el código puede ser igualmente desagradable y realmente desea emplear algún tipo de tecnología de clasificación/enlace XML (como JiBX en Java) que convertirá su XML directamente en un objeto.

Si puede utilizar XSLT en un estilo declarativo (aunque no estoy del todo de acuerdo con que sea un lenguaje declarativo), entonces creo que es útil y expresivo.

He escrito aplicaciones web que usan un lenguaje OO (C# en mi caso) para manejar la capa de procesamiento/datos, pero generan XML en lugar de HTML.Luego, los clientes pueden consumirlo directamente como una API de datos o representarlo como HTML mediante XSLT.Debido a que C# generaba XML que era estructuralmente compatible con este uso, todo fue muy fluido y la lógica de presentación se mantuvo declarativa.Fue más fácil de seguir y cambiar que enviar las etiquetas desde C#.

Sin embargo, a medida que requiere más lógica de procesamiento en el nivel XSLT, se vuelve complicado y detallado, incluso si "obtiene" el estilo funcional.

Por supuesto, hoy en día probablemente habría escrito esas aplicaciones web utilizando una interfaz RESTful, y creo que los "lenguajes" de datos como JSON están ganando terreno en áreas en las que XSLT ha transformado tradicionalmente XML.Pero por ahora XSLT sigue siendo una tecnología importante y útil.

Pasé mucho tiempo en XSLT y descubrí que, si bien es una herramienta útil en algunas situaciones, definitivamente no es una solución para todos.Funciona muy bien para fines B2B cuando se utiliza para la traducción de datos para entrada/salida XML legible por máquina.No creo que esté en el camino equivocado al afirmar sus limitaciones.Una de las cosas que más me frustró fueron los matices en las implementaciones de XSLT.

Quizás deberías consultar algunos de los otros lenguajes de marcado disponibles.Creo que Jeff escribió un artículo sobre este mismo tema relacionado con Stack Overflow.

¿Es HTML un lenguaje de marcado humano?

Echaría un vistazo a lo que escribió.Probablemente pueda encontrar un paquete de software que haga lo que quiere "listo para usar", o al menos muy cerca en lugar de escribir sus propias cosas desde cero.

Actualmente tengo la tarea de extraer datos de un sitio público (sí, lo sé).Afortunadamente, se ajusta a xhtml, por lo que puedo usar xslt para recopilar los datos que necesito.La solución resultante es legible, limpia y fácil de cambiar si es necesario.¡Perfecto!

He usado XSLT antes.El grupo de 6 archivos .xslt (refactorizado a partir de uno grande) tenía aproximadamente 2750 líneas mucho antes de que lo reescribiera en C#.El código C# tiene actualmente 4000 líneas que contienen mucha lógica;Ni siquiera quiero pensar en lo que habría sido necesario para escribir en XSLT.

El punto en el que me di por vencido fue cuando me di cuenta de que no tener XPATH 2.0 estaba perjudicando significativamente mi progreso.

Para responder a tus tres preguntas:

Utilicé XSLT una vez hace algunos años.
Creo que XSLT podría ser la solución adecuada en determinadas circunstancias.(Nunca digas nunca)
Tiendo a estar de acuerdo con su evaluación de que es principalmente útil para transformaciones "simples".Pero creo que siempre que entiendas bien XSLT, hay razones para usarlo para tareas más grandes, como publicar un sitio web como XML transformado en HTML.

Creo que la razón por la que a muchos desarrolladores no les gusta XSLT es porque no comprenden el paradigma fundamentalmente diferente en el que se basa.Pero con el reciente interés en la programación funcional, es posible que veamos el regreso de XSLT...

Un lugar donde realmente brilla xslt es en la generación de informes.Descubrí que es un proceso de 2 pasos: el primer paso exporta los datos del informe como un archivo xml y el segundo paso genera el informe visual desde el xml usando xslt.Esto permite generar informes visuales agradables y al mismo tiempo mantener los datos sin procesar como mecanismo de validación si es necesario.

En una empresa anterior hicimos mucho con XML y XSLT.Tanto XML como XSLT son grandes.

Sí, hay una curva de aprendizaje, pero luego tienes una herramienta poderosa para manejar XML.E incluso puedes usar XSLT en XSLT (lo que a veces puede resultar útil).

El rendimiento también es un problema (con XML muy grande), pero puede abordarlo utilizando XSLT inteligente y realizando un preprocesamiento con el XML (generado).

Cualquiera con conocimientos de XSLT puede cambiar la apariencia del producto terminado porque no está compilado.

A mí personalmente me gusta XSLT y es posible que quieras darle el sintaxis simplificada un vistazo (sin plantillas explícitas, solo un archivo HTML antiguo normal con algunas etiquetas XSLT para asignar valores), pero no es para todos.

Tal vez sólo quieras ofrecer a tus autores una interfaz Wiki o Markdown sencilla.También hay bibliotecas para eso, y si XSLT no funciona para usted, tal vez XML tampoco funcione para ellos.

XSLT no es el fin de la transformación xml.Sin embargo, es muy difícil juzgar basándose en la información proporcionada si habría sido la mejor solución a su problema o si existen otros enfoques más eficientes y fáciles de mantener.Dice que los autores podrían ingresar su contenido en un formato simplificado: ¿qué formato?¿Cajas de texto?¿A qué tipo de html lo estabas convirtiendo?Para juzgar si XSLT es la herramienta adecuada para el trabajo, sería útil conocer las características de esta transformación con más detalle.

Disfruto usando XSLT sólo para cambiar la estructura de árbol de documentos XML.Me resulta engorroso hacer cualquier cosa relacionada con el procesamiento de texto y relegarlo a un script personalizado que puedo ejecutar antes o después de aplicar un XSLT a un documento XML.

XSLT 2.0 incluía muchas más funciones de cadena, pero creo que no se adapta bien al lenguaje y no hay muchas implementaciones de XSLT 2.0.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow