¿Vale la pena XSLT? [cerrado]

Hace un tiempo, comencé con un proyecto en el que diseñé un esquema XML al estilo html para que los autores pudieran escribir su contenido (material educativo del curso) en un formato simplificado que luego se transformaría en HTML a través de XSLT. Jugué (luché) con él por un tiempo y lo llevé a un nivel muy básico, pero luego estaba demasiado molesto por las limitaciones que estaba encontrando (que bien pueden haber sido limitaciones de mi conocimiento) y cuando leí un blog sugiriendo deshacerme XSLT y simplemente escriba su propio analizador XML para cualquier analizador en el idioma de su elección, salté con entusiasmo a eso y funcionó de manera brillante.

Todavía estoy trabajando en eso hasta el día de hoy (en realidad se supone que debo estar trabajando en eso ahora, en lugar de jugar en SO ), y veo más y más cosas que me hacen pensar que la decisión de deshacerme de XSLT fue una 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 TheDailyWTF . 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ía que siga el camino que yo hice o que se quede con XSLT ?

Ventajas de XSLT:

• XML específico de dominio, 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 forma que las expresiones regulares pueden ser una buena forma de consultar cadenas.
• Idioma funcional.

Desventajas de XSLT:

• Puede ser obscenamente detallado: no tiene que citar XML literal, lo que significa que sí tiene que citar código. Y no de una manera bonita. Pero, de nuevo, no es mucho peor que el típico SSI.
• 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 pistas sobre cómo implementar funciones que asumieron que simplemente estarían allí y no se dieron tiempo para escribir.
• Idioma funcional.

Una forma de obtener el comportamiento procedimental, por cierto, es encadenar múltiples transformaciones juntas. Después de cada paso, tiene un DOM nuevo en el que trabajar y que refleja los cambios en ese paso. Algunos procesadores XSL tienen extensiones para hacer esto de manera efectiva en una 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 ordenada de expresarlo. Si hay mucha lógica, pero la mayoría de las formas que están integradas en XSLT (seleccione todos los elementos que se vean como bla, y para cada uno de ellos salga bla), es probable que sea un entorno bastante amigable. Si le apetece pensar en XML en todo momento, pruebe XSLT 2.

De lo contrario, diría que si su lenguaje de programación favorito tiene una buena implementación DOM que admite XPath y le permite 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 vergonzoso apegarse a lenguajes de uso general que conoce bien.

Los analizadores XML de cosecha propia suelen estar incompletos (en cuyo caso se despegará algún día) o no mucho más pequeños que algo que podría haber sacado de la estantería (en cuyo caso probablemente esté perdiendo el tiempo), y da usted muchas oportunidades para introducir problemas de seguridad graves en torno a 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.

¡Tanta negatividad!

He estado usando XSLT durante algunos años y realmente me encanta. La clave que debes tener en 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 en bruto o en representación de memoria. XSLT y XPath le brindan una forma enormemente 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 capacidades de utilidad: eliminar espacios de nombres, reconocer definiciones de esquemas dispares, fusionar documentos.

Se debe ser mejor para hacer frente a 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, la naturaleza le permitirá mantener a la mayoría 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 se transforma en JSON, HTML o XML según lo solicite el usuario final. Tuve 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 unos pocos archivos de clase y que el servidor tenía instalado MS Office. Resulta que Excel tiene un XSD: nueva funcionalidad con un 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 defectuosa de la herramienta.

Evidentemente, creo firmemente que "merece la pena".

Tengo que admitir un sesgo aquí porque enseño XSLT para ganarme la vida. Pero podría valer la pena cubrir las áreas en las que veo trabajar a mis estudiantes. Generalmente, se dividen en tres grupos: publicación, banca y web.

Muchas de las respuestas hasta ahora podrían resumirse como "no sirve para crear sitios web" o "no se parece en nada al lenguaje X". Mucha gente de tecnología pasa por sus carreras sin exposición a lenguajes funcionales / declarativos. Cuando estoy enseñando, la gente con experiencia en Java / VB / C / etc son los que tienen problemas con el lenguaje (las variables son variables en el sentido del álgebra, no de programación procedimental, 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 lo hace trivial. Los estudiantes que veo en este espacio tienden a procesar conjuntos de datos y presentarlos en la web. XSLT ciertamente no es la única herramienta aplicable en este espacio. Sin embargo, muchos de ellos están usando 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 usa para sentarse entre servicios que "hablan" diferentes dialectos XML. La transformación de un lenguaje XML a otro es casi trivial en XSLT y la cantidad de estudiantes que asisten a mis cursos sobre este tema está aumentando.

El grupo final de estudiantes que veo provienen de una experiencia editorial (como yo). Estas personas tienden a tener inmensos documentos en XML (créanme, la publicación como industria se está volviendo muy importante en XML; la publicación técnica ha estado allí durante años y la publicación comercial está llegando 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 codificador no haya tenido realmente la idea: XSLT tiene una mentalidad muy diferente a la de muchos otros idiomas. Si no tiene la mentalidad, no funcionará.

Ciertamente no es un idioma moribundo (la cantidad de trabajo que obtengo me lo dice). En este momento, está un poco "atascado" hasta que Microsoft termine su implementación (muy tarde) de XSLT 2. Pero todavía está ahí y parece ir fuerte desde mi punto de vista.

Usamos XSLT ampliamente para cosas como la documentación y para hacer que algunos ajustes de configuración complejos sean útiles para el usuario.

Para la documentación, usamos mucho DocBook, que es un formato basado en XML. Esto nos permite almacenar y administrar nuestra documentación con todo nuestro código fuente, ya que los archivos son texto sin formato. 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 hacer que el contenido sea más legible. Por ejemplo, cuando publicamos notas de la versión, podemos crear XML que se parezca a lo siguiente:

<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 (PDF o HTML generalmente) donde las ID de error 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 a nuestro rastreador de errores qué ha cambiado entre las versiones.

El otro lugar donde hemos encontrado que XSLT es útil es en realidad en nuestro producto principal. A veces, al interactuar con sistemas de terceros, necesitamos procesar datos de alguna manera en una página HTML compleja. Analizar HTML es feo, por lo que alimentamos los datos a través de algo como TagSoup(que genera eventos XML SAX adecuados, esencialmente permitiéndonos manejar el HTML como si estuviera escrito correctamente en XML) y luego podemos ejecutar algo de XSLT en él, para convertir los datos en un formato "estable conocido" con el que podamos trabajar. . Al separar esa transformación en un archivo XSLT, eso significa que si cambia el formato HTML, 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 enviar un correo electrónico ellos un archivo XSLT actualizado sin necesidad de actualizar todo el sistema.

Diría que para los proyectos web, hay mejores formas de manejar el lado de la vista que XSLT hoy, 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 perspectiva, todavía tiene muchos usos buenos.

XSLT es un ejemplo de lenguaje de programación declarativo .

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 están muy bien diseñados y son 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 de OO o de procedimiento más convencionales que son difíciles de aprender y depurar. Su naturaleza compacta generalmente hace que sea muy fácil hacer mucho daño inadvertidamente.

Entonces, si bien XSLT es un mecanismo eficiente para fusionar datos en presentaciones, 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 de poder construir una interfaz de usuario HTML completa con una transformación 'simple'.

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

Prefiero roer mi propia pierna que usar un XSLT, mientras que hay mejores formas de hacer las cosas. Aún 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 alrededor de una docena de archivos separados (hizo muchas cosas: encabezados para clientes, proxies / stubs remotos, envoltorios COM, envoltorios .NET, ORM, por nombrar unos pocos). Lo heredé de otro chico que realmente no entendía bien el idioma y, en consecuencia, las partes más antiguas fueron un desastre. Sin embargo, las cosas más nuevas que escribimos se mantuvieron cuerdas y legibles, 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 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) usualmente era varias veces más largo. Muy a menudo, sin embargo, recibe críticas inmerecidas debido al uso innecesario de XML en algunos casos en primer lugar.

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

Yo uso XSLT (por falta de una mejor alternativa), pero no para presentación, solo para transformación:

1. Escribo transformaciones XSLT cortas para hacer ediciones masivas en nuestros archivos maven pom.xml.

2. Escribí una serie de transformaciones para generar esquemas XML desde XMI (diagrama UML). Funcionó durante un tiempo, pero finalmente se volvió demasiado complejo y tuvimos que sacarlo detrás del granero.

3. He usado transformaciones para refactorizar esquemas XML.

4. 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 intercambiando el XML que está procesando que otros enfoques que he probado, que me han parecido innecesariamente con pérdidas o simplemente malinterpretan el XML. XSLT es desagradable, pero encuentro usar Oxygen lo hace soportable.

Dicho esto, estoy investigando el uso de Clojure (un lisp) para realizar transformaciones de XML, pero aún no he avanzado lo suficiente como para saber si ese enfoque me traerá beneficios.

Personalmente usé 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 usando 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 los componentes que estaban incrustados con relativa facilidad, que 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ástico. Sin embargo, no es la única forma de definir un algoritmo que toma XML como entrada y genera 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, imagino que la mejor idea sería crear su propia conversión XML-> XML que siga la lógica de su negocio. A continuación, escriba un traductor XSLT que solo sepa formatear y no haga nada inteligente. Ese 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 políglotas (X) (presentando 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 tu caja de herramientas, pero solo debes usarla cuando sea apropiado.

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

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

W3schools tiene dos artículos que son de particular 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 del "nivel intermedio" estaban en XML, y que las páginas debían renderizarse en HTML, que bien podría ser XHTML, además de que habían escuchado que XSL era un estándar para la transformación entre XML formatos. Así que los "arquitectos" (con lo que me refiero a las personas que piensan profundamente en el diseño pero aparentemente nunca codifican) decidieron que nuestro primer nivel se implementaría escribiendo scripts XSLT que transformaran los datos en XHTML para su visualización.

La elección resultó desastrosa. Resulta que XSLT es un dolor de cabeza para escribir. Así que todas nuestras páginas fueron difíciles de escribir y mantener. Habríamos hecho mucho mejor si hubiéramos usado JSP (esto estaba 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.

Su 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 se haya encontrado con el mismo tipo de dificultad que yo. Yo diría que intentar interpretar un DSL (lenguaje específico de dominio) simple basado en XML 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 tenía era más simple: tiene datos en un formato XML y desea realizar modificaciones simples, no un DSL de descripción de página completa, sino algunas modificaciones sencillas y directas, entonces XSLT es una herramienta excelente 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 usa XPath, entonces está en camino de aprender programación funcional y esto lo expondrá a nuevas técnicas y formas de resolver problemas. En algunos casos, la transformación sucesiva es más poderosa que las soluciones procedimentales.

Utilizo XSLT ampliamente, para un front-end de estilo MVC personalizado. El modelo se "serializa" a xml (no a través de serialización xml) y luego se convierte a html a través de xslt. La ventaja sobre ASP.NET radica en la integración natural con XPath y los requisitos de forma más rigurosa (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 la salida de otra transformación) lo que significa que ocasionalmente es frustrante trabajar con él.

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

Usé XML, XSD y XSLT en un proyecto de integración entre sistemas DB 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 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 empleaba las bibliotecas Xerces.

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

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

Aunque no tuve muchos problemas para aprender la naturaleza declarativa XSD y XSLT, encontré que otros programadores de C / C ++ tenían grandes problemas para adaptarse a la forma declarativa. Cuando vieron que era todo, ¡ah procedimental murmuraron, ahora que lo entiendo! ¡Y procedieron (¿juego de palabras?) A escribir XSLT procesal. Lo que pasa es que tienes que aprender XPath y comprender los ejes de XML. Me recuerda a los antiguos programadores de C que se adaptaban al empleo de OO al escribir C ++.

Usé estas herramientas ya que 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 fueron 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. Quiero decir que 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 tratado de aprenderlo unas 5 veces en mi carrera, y simplemente no funciona.

De acuerdo, podría "manipularlo", creo que ese fue en parte el objetivo de su diseño, pero ese es el segundo error: todas las herramientas XSLT en el mercado son, simplemente, ¡una mierda!

La especificación XSLT define XSLT como "un lenguaje para transformar documentos XML en otros documentos XML". Si está intentando hacer cualquier cosa 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:

• Documentación de MSDN
• CSharpFriends: Tutorial

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 tener que codificar. Es solo cuestión de cambiar el XSLT.

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

Además, al usar XSLT, está trabajando más cerca de su dominio de problemas (HTML). Siempre lo considero una buena idea.

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

Todo se reduce a para qué lo necesita. Su principal fortaleza es la facilidad de mantenimiento de la transformación, y escribir su propio analizador generalmente lo borra. Dicho esto, a veces un sistema es pequeño y simple y realmente no necesita una solución "elegante". Siempre que su constructor 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 feo. Sí, se necesita algo de tiempo para acostumbrarse. Pero una vez que aprendas a hacerlo (no debería tomar mucho tiempo en mi opinión), en realidad es viento en popa. Las transformaciones compiladas se ejecutan bastante rápido en mi experiencia, y ciertamente puedes depurarlas.

Sigo creyendo que XSLT puede ser útil, pero es un lenguaje feo y puede conducir a un lío terrible, ilegible e imposible de mantener. En parte porque XML no es lo suficientemente legible por humanos para crear un "lenguaje" y en parte porque XSLT está atascado en algún lugar entre ser declarativo y procedimental. Habiendo dicho eso, y creo que se puede hacer una comparación con expresiones regulares, tiene sus usos cuando se trata de problemas simples bien definidos.

Usar el enfoque alternativo y analizar XML en 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 usar XSLT en un estilo declarativo (aunque no estoy del todo de acuerdo en 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 datos / procesamiento, 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 # estaba generando XML que era estructuralmente compatible con este uso, todo fue muy fluido y la lógica de presentación se mantuvo declarativa. Era más fácil de seguir y cambiar que enviar las etiquetas desde C #.

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

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

He pasado 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 en su declaración de sus limitaciones. Una de las cosas que más me frustró fueron los matices en las implementaciones de XSLT.

Quizás debería mirar algunos de los otros lenguajes de marcado disponibles. Creo que Jeff hizo 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 (refactorizados 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 necesitado 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 sus tres preguntas:

1. He usado XSLT una vez hace algunos años.
2. Creo que XSLT podría ser la solución adecuada en determinadas circunstancias. (Nunca digas nunca)
3. Tiendo a estar de acuerdo con su evaluación de que es más útil para transformaciones "simples". Pero creo que siempre que entienda 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, podríamos ver que XSLT regresa ...

Un lugar donde xslt realmente brilla es en la generación de informes. Descubrí que un proceso de 2 pasos, con el primer paso exportando los datos del informe como un archivo xml, y el segundo paso generando el informe visual desde el xml usando xslt. Esto permite buenos informes visuales mientras se mantienen los datos sin procesar como un 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 tiene una herramienta poderosa para manejar XML. E incluso puede usar XSLT en XSLT (que a veces puede ser útil).

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

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

Personalmente, me gusta XSLT, y es posible que desee darle un vistazo a la sintaxis simplificada (sin plantillas explícitas, solo un archivo HTML antiguo normal con algunas etiquetas XSLT para escupir valores), pero simplemente no es para todos.

Tal vez solo desee ofrecer a sus autores una sencilla interfaz Wiki o Markdown. También hay bibliotecas para eso, y si XSLT no funciona para usted, es posible que XML tampoco funcione para ellas.

XSLT no es el final de la transformación xml. Sin embargo, es muy difícil juzgar con base en la información proporcionada si hubiera 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 estaba 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 solo para cambiar la estructura de árbol de documentos XML. Me resulta engorroso hacer algo relacionado con el procesamiento de texto y lo relego 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 encaja bien con el lenguaje y no hay muchas implementaciones de XSLT 2.0.