XSLT ( Extensible Stylesheet Language Transformations ) es un lenguaje diseñado originalmente para transformar documentos XML en otros documentos XML, [1] u otros formatos como HTML para páginas web , texto simple o XSL Formatting Objects , que posteriormente pueden convertirse a otros formatos, como PDF , PostScript y PNG . [2] El soporte para JSON y la transformación de texto simple se agregó en actualizaciones posteriores a la especificación XSLT 1.0.
A partir de agosto de 2022 [actualizar], la versión estable más reciente del lenguaje es XSLT 3.0, que alcanzó el estado de Recomendación en junio de 2017.
Las implementaciones de XSLT 3.0 son compatibles con Java, .NET, C/C++, Python, PHP y NodeJS. También se puede alojar una biblioteca JavaScript XSLT 3.0 dentro del navegador web. Los navegadores web modernos también incluyen compatibilidad nativa con XSLT 1.0. [3]
En una transformación de documento XSLT, no se modifica el documento original, sino que se crea un nuevo documento basado en el contenido de uno existente. [4] Normalmente, los documentos de entrada son archivos XML, pero se puede utilizar cualquier cosa a partir de la cual el procesador pueda construir un modelo de datos XQuery y XPath , como tablas de bases de datos relacionales o sistemas de información geográfica . [1]
Si bien XSLT fue diseñado originalmente como un lenguaje de propósito especial para la transformación XML, el lenguaje es Turing-completo , lo que lo hace teóricamente capaz de realizar cálculos arbitrarios. [5]
XSLT está influenciado por lenguajes funcionales [ 6] y por lenguajes de coincidencia de patrones basados en texto como SNOBOL y AWK . Su predecesor más directo es DSSSL , que hizo por SGML lo que XSLT hace por XML. [7]
El procesador XSLT toma uno o más documentos fuente XML, más una o más hojas de estilo XSLT, y los procesa para producir uno o varios documentos de salida. [16] [17] A diferencia de los lenguajes de programación imperativos ampliamente implementados como C , XSLT es declarativo . [18] El paradigma de procesamiento básico es la coincidencia de patrones. [19] En lugar de enumerar una secuencia imperativa de acciones a realizar en un entorno con estado, las reglas de plantilla solo definen cómo manejar un nodo que coincida con un patrón particular similar a XPath, si el procesador encuentra uno, y los contenidos de las plantillas comprenden efectivamente expresiones funcionales que representan directamente su forma evaluada: el árbol de resultados, que es la base de la salida del procesador.
Un procesador típico se comporta de la siguiente manera. En primer lugar, suponiendo que ya se ha leído y preparado una hoja de estilo, el procesador crea un árbol de origen a partir del documento XML de entrada. A continuación, procesa el nodo raíz del árbol de origen, busca la plantilla que mejor se adapta a ese nodo en la hoja de estilo y evalúa el contenido de la plantilla. Las instrucciones de cada plantilla suelen indicar al procesador que cree nodos en el árbol de resultados o que procese más nodos en el árbol de origen de la misma forma que el nodo raíz. Por último, el árbol de resultados se serializa como texto XML o HTML.
XSLT utiliza XPath para identificar subconjuntos del árbol de documentos de origen y realizar cálculos. XPath también proporciona una variedad de funciones que XSLT amplía aún más.
XSLT 1.0 utiliza XPath 1.0, mientras que XSLT 2.0 utiliza XPath 2.0. XSLT 3.0 funcionará con XPath 3.0 o 3.1. En el caso de 1.0 y 2.0, las especificaciones XSLT y XPath se publicaron en la misma fecha. Sin embargo, con 3.0, ya no estaban sincronizadas; XPath 3.0 se convirtió en una recomendación en abril de 2014, seguida de XPath 3.1 en febrero de 2017; XSLT 3.0 le siguió en junio de 2017.
Las funcionalidades de XSLT se superponen con las de XQuery , que inicialmente fue concebido como un lenguaje de consulta para grandes colecciones de documentos XML.
Los estándares XSLT 2.0 y XQuery 1.0 fueron desarrollados por grupos de trabajo independientes dentro del W3C , que trabajaron juntos para garantizar un enfoque común cuando fuera necesario. Comparten el mismo modelo de datos, sistema de tipos y biblioteca de funciones, y ambos incluyen XPath 2.0 como sublenguaje.
Sin embargo, ambos lenguajes tienen sus raíces en tradiciones diferentes y atienden las necesidades de comunidades diferentes. XSLT fue concebido principalmente como un lenguaje de hojas de estilo cuyo objetivo principal era representar XML para el lector humano en la pantalla, en la web (como lenguaje de plantillas web ) o en papel. XQuery fue concebido principalmente como un lenguaje de consulta de bases de datos en la tradición de SQL .
Debido a que los dos lenguajes se originan en comunidades diferentes, XSLT es más fuerte en su manejo de documentos narrativos con una estructura más flexible, mientras que XQuery es más fuerte en su manejo de datos, por ejemplo al realizar uniones relacionales. [20]
El <output>
elemento puede tomar opcionalmente el atributo media-type
, que permite establecer el tipo de medio (o tipo MIME) para la salida resultante, por ejemplo: <xsl:output output="xml" media-type="application/xml"/>
. La recomendación XSLT 1.0 recomienda los tipos de atributos más generales text/xml
y, application/xml
dado que durante mucho tiempo no hubo ningún tipo de medio registrado para XSLT, durante este tiempo text/xsl
se convirtió en el estándar de facto. En XSLT 1.0 no se especificó cómo media-type
se debían usar los valores.
Con el lanzamiento de XSLT 2.0, el W3C recomendó en 2007 el registro del tipo de medio MIME application/xslt+xml
[21] y posteriormente fue registrado ante la Autoridad de Números Asignados de Internet . [22]
Los borradores de trabajo de XSLT anteriores a la versión 1.0 se utilizaron text/xsl
en sus ejemplos de incrustación, y Microsoft implementó y siguió promoviendo este tipo en Internet Explorer [23] y MSXML alrededor de 2012. También se reconoce ampliamente en la xml-stylesheet
instrucción de procesamiento de otros navegadores. Por lo tanto, en la práctica, los usuarios que querían controlar la transformación en el navegador utilizando esta instrucción de procesamiento se vieron obligados a utilizar este tipo de medio no registrado. [24]
Estos ejemplos utilizan el siguiente documento XML entrante:
<?xml version="1.0" ?> <personas> <persona nombre_usuario= "JS1" > <nombre> John </nombre> <apellido> Smith </apellido> </persona> <persona nombre_usuario= "MI1" > <nombre> Morka </nombre> <apellido> Ismincius </apellido> </persona> </personas>
Esta hoja de estilo XSLT proporciona plantillas para transformar el documento XML:
<?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet xmlns:xsl= "http://www.w3.org/1999/XSL/Transform" version= "1.0" > <xsl:output method= "xml" indent= "yes" /> <xsl:template match= "/personas" > <root> <xsl:apply-templates select= "persona" /> </root> </xsl:template> <xsl:template match= "persona" > <nombre nombreusuario= "{@nombreusuario}" > <xsl:value-of select= "nombre" /> </nombre> </xsl:template> </xsl:hoja de estilo>
Su evaluación da como resultado un nuevo documento XML, con otra estructura:
<?xml version="1.0" encoding="UTF-8"?> <root> <nombre nombre_usuario= "JS1" > John </nombre> <nombre nombre_usuario= "MI1" > Morka </nombre> </root>
Procesando el siguiente archivo XSLT de ejemplo
<?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version= "1.0" xmlns:xsl= "http://www.w3.org/1999/XSL/Transform" xmlns= "http://www.w3.org/1999/xhtml" > <xsl: método de salida= "xml" sangría= "sí" codificación= "UTF-8" /> <xsl:template match= "/persons" > <html> <head> <title> Ejemplo de prueba XML </title> </head> <body> <h1> Personas </h1> <ul> <xsl:apply-templates select= "person" > <xsl:sort select= "family-name" /> </xsl:apply-templates> </ul> </body> </html> </xsl:template> <xsl:template match= "persona" > <li> <xsl:value-of select= "apellido" /><xsl:text> , </xsl:text><xsl:value-of select= "nombre" /> </li> </xsl:template> </xsl:hoja de estilo>
Con el archivo de entrada XML que se muestra arriba se obtiene el siguiente XHTML ( aquí se han ajustado los espacios en blanco para mayor claridad):
<?xml version="1.0" encoding="UTF-8"?> <html xmlns= "http://www.w3.org/1999/xhtml" > <head> <title> Ejemplo de prueba XML </title> </head> <body> <h1> Personas </h1> <ul> <li> Ismincius, Morka </li> <li> Smith, John </li> </ul> </body> </html>
Este XHTML genera la salida a continuación cuando se procesa en un navegador web.
Para que un navegador web pueda aplicar una transformación XSL a un documento XML en pantalla, se puede insertar una instrucción de procesamiento de hoja de estilo XML en el XML. Por ejemplo, si la hoja de estilo del Ejemplo 2 anterior estuviera disponible como "example2.xsl", se podría agregar la siguiente instrucción al XML entrante original: [25]
<?xml-stylesheet href="ejemplo2.xsl" tipo="texto/xsl" ?>
En este ejemplo, text/xsl
es técnicamente incorrecto según las especificaciones del W3C [25] (que dicen que el tipo debe ser application/xslt+xml
), pero es el único tipo de medio que es ampliamente compatible con todos los navegadores a partir de 2009, y la situación no ha cambiado en 2021.
msxsl.exe
. [38] El entorno de ejecución .NET incluye un procesador XSLT integrado independiente en su System.Xml.Xsl
biblioteca.La mayoría de los primeros procesadores XSLT eran intérpretes. Más recientemente, la generación de código es cada vez más común, utilizando lenguajes intermedios portátiles (como Java bytecode o .NET Common Intermediate Language ) como objetivo. Sin embargo, incluso los productos interpretativos generalmente ofrecen fases de análisis y ejecución separadas, lo que permite crear un árbol de expresión optimizado en memoria y reutilizarlo para realizar múltiples transformaciones. Esto brinda importantes beneficios de rendimiento en aplicaciones de publicación en línea, donde la misma transformación se aplica muchas veces por segundo a diferentes documentos fuente. [42] Esta separación se refleja en el diseño de las API de procesamiento XSLT (como JAXP ).
Los primeros procesadores XSLT tenían muy pocas optimizaciones. Los documentos de hojas de estilo se leían en modelos de objetos de documento y el procesador actuaba directamente sobre ellos. Los motores XPath tampoco estaban optimizados. Sin embargo, cada vez más, los procesadores XSLT utilizan técnicas de optimización que se encuentran en lenguajes de programación funcional y lenguajes de consulta de bases de datos, como la reescritura estática de un árbol de expresión (por ejemplo, para sacar los cálculos de los bucles) y la evaluación en secuencia lenta para reducir la huella de memoria de los resultados intermedios (y permitir una "salida temprana" cuando el procesador puede evaluar una expresión, por ejemplo, following-sibling::*[1]
sin una evaluación completa de todas las subexpresiones). Muchos procesadores también utilizan representaciones de árbol que son significativamente más eficientes (tanto en espacio como en tiempo) [43] que las implementaciones DOM de propósito general.
En junio de 2014, Debbie Lockett y Michael Kay presentaron un marco de evaluación comparativa de código abierto para procesadores XSLT llamado XT-Speedo. [44]
Ejemplo: Documentos de resultados múltiples
es un lenguaje muy especializado con un marcado carácter declarativo.
{{cite journal}}
: CS1 maint: DOI inactivo a partir de septiembre de 2024 ( enlace ){{cite journal}}
: CS1 maint: DOI inactivo a partir de septiembre de 2024 ( enlace )