Es difícil evaluar las tecnologías cuando no tienes una experiencia profunda de ellas, pero por supuesto es exactamente cuando tienes que tomar tus decisiones, por lo que no hay una respuesta simple a ese dilema.
Citas dos preocupaciones: rendimiento y usabilidad. Trataré de abordar ambos a continuación.
En primer lugar, el rendimiento. El rendimiento, por supuesto, depende no solo del idioma sino también de la implementación y también de la experiencia de los usuarios. Los diferentes procesadores XSLT pueden variar ampliamente en el rendimiento, y el mismo procesador puede variar ampliamente dependiendo de cómo se use (con Saxon, por ejemplo, las personas que tienen problemas de rendimiento a menudo lo usan con DOM, que es una combinación pobre , y el rendimiento puede aumentar diez veces si utiliza el modelo de árbol nativo de Saxon en su lugar). Entonces, el primer consejo es no tomar el rendimiento en rumores, medirlo; y el segundo consejo es asegurarse de que la persona que realiza la medición tenga suficiente experiencia para no cometer errores tontos. Más fácil decirlo que hacerlo.
Crudamente, puede separar los trabajos de transformación en dos categorías: simples y complejos. Para transformaciones simples, con un buen procesador XSLT, el tiempo se dedica a analizar y serializar, y el tiempo de procesamiento XSLT apenas entra en escena. Dado que cualquier otra tecnología incurrirá en los mismos costos de análisis y serialización, la elección de la tecnología de transformación no va a hacer una gran diferencia (excepto quizás muy para la codificación de muy bajo nivel usando la transmisión, pero no muchas personas pueden pagar la programación) tiempo y habilidades necesarias para implementar eso). Para transformaciones complejas en documentos grandes, comienza a tener los mismos problemas que con la programación SQL: lograr un buen rendimiento requiere una buena interacción entre las habilidades y el conocimiento del programador y las capacidades del optimizador. Al igual que con SQL, ' Es muy fácil en un lenguaje de tan alto nivel escribir algunas declaraciones simples que dan como resultado que el procesador tenga que hacer una gran cantidad de trabajo. Pero también, al igual que con SQL, los programadores que saben lo que hacen lo harán mucho mejor que los novatos.
Segundo, usabilidad. La sintaxis basada en XML para XSLT es muy desagradable para muchas personas en el primer encuentro con el lenguaje. Pero hay buenas razones y beneficios reales para hacerlo de esta manera: existe el argumento de la "plantilla", que gran parte del código consiste en XML para escribir en el documento resultante, y la mejor manera de escribir XML es en XML. Y existe el argumento de la "reflexión"; En sistemas complejos grandes, es muy común encontrar hojas de estilo que generen hojas de estilo. Luego está el argumento de "herramientas"; si está en una tienda XML, probablemente tenga muchas herramientas XML, como editores dirigidos por sintaxis, y es bueno poder usar las mismas herramientas para manejar sus programas y sus datos. Las desventajas resultan ser bastante cosméticas en comparación: hay ' s la cantidad de pulsaciones de teclas involucradas en la edición (se arregla fácilmente con una buena herramienta de edición), y está la verbosidad del código (lo que reduce su legibilidad). La verbosidad se reduce enormemente en XSLT 2.0 con la introducción de características como expresiones regulares y funciones de hoja de estilo: muchas hojas de estilo se reducen a la mitad o un tercio de tamaño cuando aprovechan al máximo XSLT 2.0.
Su mención de DSSSL me deja con una sonrisa irónica. Nunca he usado DSSSL, pero las historias que escuché fueron que no tenía éxito porque su sintaxis era arcana y no estaba relacionada con la sintaxis de los datos (SGML). El uso de una sintaxis XML para XSLT estuvo fuertemente motivado por la experiencia con DSSSL.
Hay personas que aman XSLT y hay personas que lo odian. Como era de esperar, aquellos que lo usan mucho tienden a caer en la primera categoría. Aquellos a quienes no les gusta son generalmente aquellos que no han aprendido a "pensar a la manera XSLT". Podría argumentar que un lenguaje de programación no debería afectar su forma de pensar, pero lo hace: escribir en un lenguaje basado en reglas toma una mentalidad diferente de escribir en un lenguaje imperativo. La primera reacción de muchos programadores es que se sienten menos en control (describiendo el problema, en lugar de decirle a la computadora qué hacer paso a paso). Es muy similar a la reacción que solía ver cuando la gente se introdujo por primera vez a SQL. En estos días, las personas aprenden SQL antes en sus carreras, por lo que se requiere menos reajuste mental.
En última instancia, debe elegir una tecnología basada en criterios objetivos medibles, no en reacciones de amor / odio. Es difícil hacer esas mediciones. Pero hay muchas personas que usan XSLT de manera muy intensa y exitosa, por lo que no hay duda de que se puede hacer.