Es difícil evaluar las tecnologías cuando no tienes una experiencia profunda de ellas, pero por supuesto que es exactamente cuando tienes que tomar tus decisiones, por lo que no hay una respuesta simple para ese dilema.
Usted cita dos preocupaciones: el rendimiento y la usabilidad. Intentaré abordar ambos a continuación.
En primer lugar, el rendimiento. El rendimiento, por supuesto, depende no solo del lenguaje sino también de la implementación, y también de la experiencia de los usuarios. Diferentes procesadores XSLT pueden variar ampliamente en 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 deficiente , y el rendimiento puede aumentar diez veces si utiliza el modelo de árbol nativo de Saxon en su lugar). Entonces, el primer consejo es que no tome el rendimiento de oídas, mídalo; y el segundo consejo es asegurarse de que la persona que realiza la medición tenga la experiencia suficiente para no cometer errores tontos. Más fácilmente dicho que hecho.
Crudamente, puede separar los trabajos de transformación en dos categorías: simple y complejo. Para transformaciones simples, con un buen procesador XSLT, el tiempo se gasta en analizar y serializar, y el tiempo de procesamiento de XSLT apenas entra en escena. Dado que cualquier otra tecnología va a incurrir en los mismos costos de análisis y serialización, la elección de la tecnología de transformación no supondrá una gran diferencia (excepto quizás para la codificación de muy bajo nivel que utiliza la transmisión por secuencias, pero no mucha gente puede 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, en un lenguaje de tan alto nivel es muy fácil escribir algunas declaraciones simples que hacen que el procesador tenga que hacer una gran cantidad de trabajo. Pero también como con SQL, los programadores que saben lo que están haciendo 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 de resultados, y la mejor manera de escribir XML es en XML. Y ahí está el argumento de la "reflexión"; en grandes sistemas complejos, es muy común encontrar hojas de estilo que generan hojas de estilo. Luego está el argumento de las "herramientas"; Si está en una tienda XML, es probable que 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 estéticas en comparación: existe la cantidad de pulsaciones de tecla involucradas en la edición (que se soluciona fácilmente con una buena herramienta de edición), y existe la verbosidad del código (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 hojas 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.
Tu mención de DSSSL me deja con una sonrisa irónica. Nunca he usado DSSSL, pero las historias que escuché eran que no tenían é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 que no les gusta son generalmente aquellos que no han aprendido a "pensar de la manera XSLT". Podría argumentar que un lenguaje de programación no debería afectar su forma de pensar, pero sí 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 las personas fueron introducidas a SQL por primera vez. 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 medidas. Pero hay mucha gente que usa XSLT de manera muy intensa y exitosa, por lo que no hay duda de que se puede hacer.