Il modo più semplice di gestire le trasformazioni di stile è non occuparsene affatto, a condizione che l’utente disponga di una piattaforma adatta ad eseguire lato-client la trasformazione. Per versioni recenti di IE e Mozilla questa assunzione risulta valida, mentre per altri browser è quanto meno azzardata.
Ammesso di voler correre questo rischio, così facendo si permette all’utente finale di accedere (con il comando Visualizza>HTML o funzioni equivalenti) alla totalità dei dati contenuti nell’XML che viene trasformato dal browser in modo trasparente.
Se anche il sorgente non dovesse contenere dati sensibili (quali ad esempio username e password di utenti), resta il fatto che l’XML è in grado di fornire nella maggior parte dei casi indizi sulla struttura di backend esistente.
Per questi motivi tale pratica risulta pericolosa e quindi sconsigliabile. Comunque è sufficiente aggiungere in cima al documento XML una "processing instruction" che indichi il foglio di stile XSL da utilizzare, così come faremmo per il comune foglio di stile CSS:
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="foglio_di_stile.xsl"?>
<dati>
...
</dati>
Fogli di stile lato-server
Per evitare i problemi di cui abbiamo parlato, è quindi consigliabile eseguire la trasformazione dietro le solide mura del server.
Per realizzare lato-server tale trasformazione, con ASP ci si affida in genere a MSXML mentre con PHP c’è Sablotron XSLT Processor.
Per quanto riguarda invece JSP, l’utilizzo di XML è stato integrato con il Java Web Services Developer Pack e consente, unitamente alle librerie di tag (tag libraries) previste dal linguaggio, di svolgere la funzione di strato intermedio in modo molto conciso:
<!-- dichiarazione delle tag library utilizzate -->
<%@ taglib prefix="c" uri="http://java.sun.com/jstl/core"
%>
<%@ taglib prefix="sql" uri="http://java.sun.com/jstl/sql"
%>
<%@ taglib prefix="x" uri="http://java.sun.com/jstl/xml"
%>
<html>
<head>
<title>Trasformazione XSLT con JSP</title>
</head>
<body>
<!-- crea una variabile “xml“ per contenere i dati -->
<c:set var="xml">
<?xml version="1.0"?>
<root>
<!-- preleva i dati dal backend e scrivili in formato XML -->
...
</root>
</c:set>
<!-- crea una variabile “xsl“ per contenere il foglio di stile
-->
<c:set var="xsl">
<?xml version="1.0"?>
<xsl:stylesheet
xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<!-- scegli o scopri il formato finale richiesto -->
...
<!-- importa il foglio di stile per il formato richiesto -->
<xsl:import href="versione_html.xsl" />
</xsl:stylesheet>
</c:set>
<!-- attiva la trasformazione di stile -->
<x:transform xml="${xml}" xslt="${xsl}"/>
All'interno di questa modalità di utilizzo, XSLT ha la funzione primaria di fungere da filtro tra la logica astratta dell'applicazione, incorporata nel sorgente XML da trasformare, ed il formato finale di output, dipendente invece dal particolare device utilizzato.
Oggetto principale della trasformazione sarà quindi il testo formattato, che dovrà rispondere alla specifica sintassi HTML, WML, etc. Un po' più complesso è il trattamento delle immagini bitmap, dal momento che richiede una elaborazione separata, non realizzabile con XSLT.
Ovviamente è anche possibile rendere nella logica XML anche i parametri necessari alla creazione dell'apparato di navigazione del sito, rendere cioè dinamici anche i menu dell'interfaccia.
Per modificare i contenuti dipendentemente dal device utilizzato, il punto di partenza è quasi sempre la trasformazione identica, ovvero un foglio di stile in grado di restituire esattamente il sorgente filtro_wml.xsl::
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<!-- aggiunge i rientri per una maggiore leggibilita’ -->
<xsl:output indent="yes"/>
<!—template principale -->
<xsl:template match="/">
<xsl:apply-templates mode="copia"/>
</xsl:template>
<!—template per la copia -->
<xsl:template match="*|@*|text()" mode="copia">
<xsl:copy>
<xsl:apply-templates select="*|@*|text()" mode="copia"/>
</xsl:copy>
</xsl:template>
</xsl:stylesheet>
Di fatto il foglio di stile non copia esattamente il sorgente, ad esempio le processing instructions ed i commenti non vengono riportati in output, e tuttavia il nostro interesse è rivolto esclusivamente ai contenuti da visualizzare.
Sebbene il sorgente XML possa contenere una formattazione arbitraria, in genere si ha a che fare con HTML dal momento che possiede una espressività superiore a tutti i possibili linguaggi di output (ad eccezione ovviamente del formato PDF, che non è ottenibile con le sole trasformazioni XSLT).
A questo punto possiamo iniziare a filtrare i contenuti in relazione al formato di output: se ad esempio volessimo scrivere un foglio di stile per tradurre i contenuti da HTML a WML, dovremmo convertire grassetti e corsivi (i tag <b> e <i> del primo) nel corrispettivo WML <strong> ed <em>.
Per ognuno di essi andremo a scrivere un template apposito che gestisca la traduzione:
<xsl:template match="b" mode="copia">
<!-- crea l’elemento WML -->
<strong>
<!-- copia il contenuto del tag HTML -->
<xsl:apply-templates mode="copia"/>
</strong>
</xsl:template>
<xsl:template match="i" mode="copia">
<em>
<xsl:apply-templates mode="copia"/>
</em>
</xsl:template>
Alcuni elementi di HTML non hanno invece un corrispettivo all’interno di WML e andranno semplicemente eliminati dall’output. Per alcuni di essi, ad esempio blockquote, l’eliminazione non dovrà estendersi al contenuto del tag, che potrebbe costituire testo perfettamente visualizzabile. Di altri elementi (applet, object, embed) andrà invece eliminato anche il contenuto:
<!-- gestisce l’evento e continua a copiare -->
<xsl:template match="blockquote" mode="copia">
<xsl:apply-templates mode="copia"/>
</xsl:template>
<!-- gestisce l’evento e non procede oltre -->
<xsl:template match="applet|object|embed" mode="copia"
/>
L’utilizzo dei fogli di stile come filtro tra un formato è l’altro mette in luce le differenze tra il modello di esecuzione di XSLT ed i linguaggi di scripting tradizionali: l’aggiunta di un template per gestire nuovi elementi non implica infatti alcuna modifica ai template precedenti.
