¿Hay buenas razones para usar, aprender o recomendar XSLT? [cerrado]

Soy desarrollador durante los últimos 8 años. Utilizamos XSLT principalmente para transformar XML en HTML. También lo usamos para la transformación de XML a XML.

Pero tenemos reemplazo para todo ahora. HTML se puede crear cómodamente a través de lenguajes de programación como ASP.Net. XML puede leerse y manipularse en cualquier lenguaje estándar de alto nivel. Como la programación en XSLT es un poco compleja, cualquiera preferiría trabajar en los últimos lenguajes de programación.

Ahora mi pregunta: ¿Será XSLT una opción importante en el futuro, sin tener en cuenta el hecho de mantener XSLT ya desarrollado? ¿Puedo recomendar nuevos programadores para estudiar XSLT?

Hay algunos casos importantes en los que XSLT puede ser una buena opción:

• El software ETL ( Extraer, Transformar, Cargar ) puede en algunos casos usar XSLT. Por ejemplo, puede ser una buena opción cuando los datos extraídos y los datos para cargar están en un formato XML, y donde la transformación se puede cambiar sin la necesidad de volver a compilar la aplicación.

• Algunas aplicaciones que almacenan datos en XML usan XSLT para presentar estos datos en un formato legible por humanos¹. Por ejemplo, Windows Live Messenger almacena la traza de mensajes como XML, pero cuando abre el historial en WLM, le muestra una bonita tabla que, de hecho, es HTML creado a través de XSLT.

• Algunos sitios web orientados a desarrolladores u orientados a datos pueden querer dar acceso a XML si la intención es utilizar las páginas del sitio web mediante programación². De alguna manera es mejor usar analizadores HTML, especialmente porque el código HTML se puede cambiar en cualquier momento.

• XSLT, cuando se usa en sitios web, permite una separación estricta entre HTML y código subyacente, lo que permite contratar un desarrollador para código subyacente y otro desarrollador para material HTML / CSS. Vea el punto 1 en mi respuesta a otra pregunta .

¿Será XSLT una elección importante en el futuro? Bueno, esta no es una opción importante hoy, y dudo que el uso de XSLT aumente con el tiempo. Ignoro la razón de eso, pero a muchos desarrolladores no les gusta XML y odian XSLT.

¿Me puede recomendar nuevos programadores para estudiar XSLT? ¡Seguro! No solo XSLT se puede usar en algunas circunstancias cuando otros enfoques serían más difíciles, sino que también XSLT tiene un enfoque muy específico que otros lenguajes no tienen.

^{¹ Con esto quiero decir que XML no es realmente legible para los humanos: si le preguntas a una persona que no trabaja en TI que lea XML, se horrorizará.
² Sé que hay servicios web. Pero a veces es más fácil y más sencillo, en cada página, construir un objeto dinámico, luego serializarlo a XML y luego transformarlo a HTML a través de XSLT o dejar que el bot acceda al XML directamente.}

XSLT está prácticamente muerto porque solo unos pocos entusiastas todavía lo usan. Sin embargo, no hay una alternativa real para ello. Si se enfoca solo en un caso de uso único, como por ejemplo la representación de páginas HTML a partir de documentos semánticos, encontrará mejores herramientas. Si busca motores de plantillas de generación de código, nuevamente hay mejores herramientas. Lo mismo para la transformación de documentos.

Pero si busca una herramienta que admita todos estos casos de uso bastante bien en todas las plataformas, las opciones son muy limitadas. Si ya tiene un documento XML y tendría que transformarlo en algo para poder usar su herramienta, probablemente sea mejor que solo procese sus datos con XSLT (o XQuery).

De cualquier manera, puedes aprender XSLT en cuestión de días, tal vez semanas. No te hará daño hacer una experiencia de primera mano. Solo inténtalo. Al menos vale la pena el esfuerzo de almacenar este tipo de patrón (transformaciones basadas en reglas) en su cabeza para su uso posterior. Esto solo justifica el aprendizaje de XSLT.

Hmm, me pregunto si las API de alto nivel que crean HTML a partir de código usan algún XSLT "oculto" ...

XSLT se usa ampliamente donde trabajo para transformar XML de un formato de origen a una variedad de otros. También se puede usar para transformar XML en salida no XML. No he hecho mucho de esto, pero he oído que se está haciendo para apuntar a PDF y PostScript, entre otros.

Sí.

Tomemos un buen ejemplo: informes de pruebas unitarias en integración continua. La mayoría de las pruebas unitarias y los programas de cobertura de código simplemente generan toneladas de XML ilegible. Pero con unos pocos XSLT simples, puede crear una docena de informes útiles a partir de los mismos datos. Y otras personas pueden reutilizar esos informes.

Ahora puede escribirlos en cualquier idioma que la herramienta CI use para los complementos, pero si no conoce ese idioma (por ejemplo, es un desarrollador de .NET, usa Jenkins), entonces no hay necesidad de aprenderlo. Simplemente use un complemento que ya aplique un XSLT a un archivo XML y escriba algunos XSLT útiles.

Siempre habrá opciones y variedad en los lenguajes de programación, y las razones por las cuales uno es elegido con preferencia a otro tienen tanto que ver con la familiaridad y la moda como con criterios objetivos como la funcionalidad, la productividad y el rendimiento. Nadie puede predecir la moda, por lo que nadie puede predecir tendencias futuras en lenguajes de programación. Pero hay muchas personas que han superado las barreras de aprendizaje iniciales para XSLT y encuentran que es una herramienta extremadamente productiva para una gran variedad de tareas (posiblemente una variedad más amplia de la que alguna vez fue diseñada para abordar).

Para muchas de las tareas en las que veo que se usa XSLT (y las tareas que lo uso para mí), escribir código Java o ASP para hacer el trabajo sería un desperdicio terrible del presupuesto de su empleador. Pero quizás no, si eres bueno escribiendo Java y malo escribiendo XSLT.

XSLT no es legible para humanos. La metainformación (las etiquetas) ocupa demasiado lugar sobre la información real (texto, solicitudes xpath). Un buen código debería verse como una documentación y este no es el caso de XSLT. Es más bien un buen formato de persistencia para las herramientas de mapeo.

Un buen lenguaje de transformación debería permitir obtener una vista previa del resultado de la transformación y ver el flujo de transformación (SI, ELSE, FOR, WHILE) simultáneamente. Esto es importante para la mantenibilidad. Con respecto a este aspecto, Velocity o GenearateXY son mejores que XSLT. GenerateXY es incluso un poco mejor ya que separa la vista previa y el flujo, mientras que con Velocity, desafortunadamente, tendría que romper la sangría de vista previa para proporcionar un flujo legible.

El único punto bueno en XSLT es que se preocupa por la modularidad al usar e incluso abusar de los elementos "xsl: template". El problema con esto es que es bueno para un lenguaje de procesamiento de datos (Java, C, ...) pero muy secundario para un lenguaje de presentación.

En efecto

Algo probablemente reemplazará a XSLT algún día, ya que es un poco engorroso aprender y usar. Sin embargo, actualmente no hay un lenguaje de plantilla / transformación disponible afaik que sea tan flexible y "puro" en su implementación.

XSL-T se puede usar para diferentes propósitos:

• Puede "crear" contenido en formato HTML a partir de datos utilizando una plantilla
• Puedes convertir de un formato xml a otro
• Puede manipular xml en otro formato, tal vez mostrar un subconjunto

Básicamente, todo esto es lo mismo, sin embargo, la transformación de un archivo de datos XML a otro. Ahora veamos algunas herramientas diferentes que podríamos usar en lugar de XSLT.

Si quisiéramos manipular el contenido de, digamos, una página XHTML, podríamos usar regexp, pero regexp es complicado para cosas estructurales. Brilla para manipular cadenas, pero no lo usaría para crear una tabla de contenido para algo o presentarlo en un diseño diferente.

El siguiente es ASP.Net. Ponemos nuestro diseño en nuestra página asp e insertamos algo de código para las partes dinámicas. Otra alternativa es renunciar a la parte del diseño y generar todo, por ejemplo, una base de datos y usar C # creando nuestra salida deseada.

El problema con el primer enfoque es que es torpe pasar de datos descriptivos a contenido real. Si tiene algún archivo de datos que contiene números de teléfono que desea presentar con encabezados para cada letra, muestre un número total de entradas, etc. Tendría que tener parte del diseño en el archivo de diseño y algo en el código que está generando . Otra opción es usar alguna forma de cuadrícula web, creo que son bastante desordenadas y de repente tienes que aprender cómo funciona la cuadrícula cuando todo lo que querías hacer era generar un html específico dados los datos.

Ir totalmente dinámico es ciertamente una opción, pero también es bastante torpe. Incluso en el mejor caso en el que esté usando algo como LINQ, tendrá que mezclar el código de programación con la salida de una manera bastante fea. Además, no hay una buena manera de manejar correctamente el contenido recursivo no estructurado de estilo de documento que suele ser el HTML.

Con XSLT, simplemente puede hacer una plantilla para una determinada etiqueta, tal como es o en el contexto de su padre, por lo que se representa de manera diferente si, por ejemplo, es parentet por otra cosa.

Una respuesta bastante larga, pero sí, creo que hay un gran valor en un lenguaje de plantilla descriptivo y XSLT es el mejor y más estandarizado que hemos obtenido hasta ahora.

El mayor fallo de XSLT es su incapacidad (en cualquier implementación real) para minimizar la cantidad de documento que debe mantenerse en la memoria a la vez para un procesamiento eficiente. En cambio, todo el documento se lee en alguna forma de representación DOM y el procesamiento se realiza en contra de eso. Si el documento es muy grande, también lo son los requisitos de memoria. Sin embargo, muchas hojas de estilo claramente solo necesitan la etiqueta actual y algunas otras, por ejemplo, los antepasados ​​de la etiqueta, en cualquier momento dado y, por lo tanto, podrían procesarse con una memoria mínima y una transmisión eficiente.

Sí, en términos de un idioma es extraño, pero eso es solo una barrera de entrada. Si conoce XSLT, a menudo es más fácil que las alternativas, pero si tendrá documentos grandes (o muchos documentos procesados ​​a la vez), el impacto en la memoria de XSLT a menudo obliga a otras alternativas que requieren más tiempo.

De hecho, creo que es más eficiente usar XSL que otro lenguaje para presentar datos. Por ejemplo, puede presentar un XML como PDF utilizando XSL-FO y puede controlar cada pulgada, pero si trabaja con RDLC (.NET), por ejemplo, verá que es muy difícil presentar exactamente lo que desea.

Incluso la evolución / corrección es bastante fácil, ya que en XSL cada elemento tiene su propia plantilla. Creo que la extensión de XSL es más importante como XSLT y XSL-FO. Es por eso que este lenguaje todavía se usará en el futuro (pero realmente espero que sea más estable y menos complejo).

Trabajo para una empresa de integración de datos y utilizamos XSLT con nuestras herramientas propietarias como una excelente solución que involucra XML a HTML / XML / Ascii.