De acuerdo a la forma como se programan, las XSPs se pueden dividir en tres grupos:
Con la l�gica embebida en la presentaci�n
Con hojas de estilos
Con bibliotecas etiquetas
En este tipo de p�ginas se escribe el c�digo en la propia p�gina XML. �sta es la pr�ctica de programaci�n menos recomendada y no deber�a utilizarla nunca, ya que aunque puede funcionar, el mantenimiento se torna muy complicado y la reutilizaci�n se minimiza brutalmente.
Para hacer el tratamiento de este tipo de XSP, el procesador XSP analiza el XML y convierte la p�gina en un Servlet compilado. Esto lo hace llevando el XML a Java mediante un �rbol DOM. Una vez llevado a c�digo Java, se procesa y al resultado final se le aplica una transformaci�n XSLT para llevar el resultado final a una p�gina HTML.
Como podemos ver esta forma de programaci�n, degrada el c�digo XML ya que lo combina con el Java, por lo tanto la separaci�n entre contenido y presentaci�n de la cual hemos hablando no se hace presente. Este tipo de forma de programar no deber�a ser utilizada en ning�n caso a menos que sea estrictamente necesario (aunque a decir verdad nunca deber�a ser estrictamente necesaria).
Esta forma de programar las XSP es mucho m�s recomendable que la anterior. En �sta, la p�gina XSP original ser�a vista como un documento XML que se vale de hojas de estilos para aplicar la l�gica de la programaci�n, es decir el c�digo Java. Cuando el documento XML original es procesado, se le aplica la transformaci�n y como resultado se tiene una p�gina XSP con el c�digo embebido.
Note que en este caso el mantenimiento de la p�gina mejora bastante con respecto al modelo que se expuso anteriormente, sin embargo la reutilizaci�n es muy pobre ya que el c�digo fuente Java que se necesite para otra p�gina XSP se debe incluir en otra XSL distinta.
La idea de esta forma de implementar XSP es tener en bibliotecas especializadas, etiquetas que se encarguen de ejecutar cierto proceso, cierta funci�n o procedimiento escrito en un lenguaje de programaci�n (como por ejemplo Java) para que dichas bibliotecas puedan ser incluidas mediante espacios de nombres en los ficheros XML que las necesitan y as� mismo se puedan utilizar las funciones que proveen dichas bibliotecas.
Estas bibliotecas deber�an agruparse por roles o por tipos de funciones o servicios que proveen.
Como vemos en este caso el problema que aun ten�amos, reutilizaci�n de c�digo se vuelve imperceptible y no existe, ya que las bibliotecas y los servicios que proveen son independientes del fichero XML que las utiliza.