Este anexo sirve para resumir las tecnologías básicas XML empleadas a lo largo de la tesis, así como ciertas utilidades y estándares asociados.

Transcripción

1 ANEXO B: ESTÁNDARES Y UTILIDADES XML Este anexo sirve para resumir las tecnologías básicas XML empleadas a lo largo de la tesis, así como ciertas utilidades y estándares asociados.

2 B.1 Tecnologías Básicas en XML...1 B.1.1 XML Schema...3 B Características básicas... 4 B Namespace... 4 B Elementos... 7 B Atributos B Características específicas B Trabajo con varios Schemas B.1.2 XSLT B Reglas B Ejemplos de Hoja de Estilo B Transformación a XML B Transformación a HTML B Transformación a texto plano B EXSLT B XSL-FO B.1.3 Schematron B Utilidad y Funcionamiento B El Schematron schema B Reglas extendidas B Meta-hoja de estilo: Skeleton B Schematron embebido en un schema B Extensibilidad SCHEMATRON B XML Schema y Schematron B.2 Apache Ant...32 B.2.1 introducción B.2.2 fichero de configuración B Proyecto y Propiedades B Targets y Dependencias B Tareas B.2.3 Verificaciones XML con ant B Task Checkxml B Task Checkschema B Task Xslt B.3 Cocoon...37 B.4 Chaperon...41 B Formato Fichero xlex B Formato Fichero xgrm B Formato Fichero grm B Ejecución desde Jakarta Ant B Ejecución desde Apache Cocoon B Diseño B Pipeline... 47

3 B.5 SVG (Scalable Vector Graphics)...49 B.5.1 Características Generales B.5.2 Elementos básicos B Rectangulo B Line B Circle B Elipse B Polygon B Polyline B Path B Text B Eventos y Scripts... 56

4

5 B..1 1 TECNOLOGÍÍAS BÁSIICAS EN XML Descripción general de las tecnologías XML que se utilizan en el entorno. La comprensión de estas tecnologías es necesaria para entender dónde y cómo encajan dentro del entorno. Las siglas de su nombre (extensible Markup Language) hablan de un lenguaje de marcado extensible, pero parece más correcto denominarlo metalenguaje que lenguaje extensible. XML en un metalenguaje porque ofrece la capacidad de describir nuevos lenguajes (también denominados gramáticas ó vocabularios en la bibliografía), no simplemente extensiones a un determinado lenguaje de marcas. El mecanismo utilizado para ello es el Schema, entendido éste como la descripción formal de un nuevo lenguaje XML. Evidentemente, es necesario usar un lenguaje especializado ó lenguaje de schema para construir estas descripciones y en este punto son varias las alternativas. Cada lenguaje de schema constituye un conjunto de especificaciones que pueden usarse para expresar descripciones formales de familias de documentos XML. El resultado de su uso, el Schema, se puede usar con propósitos de documentación (sintetiza todo lo común y lo variable en el tipo de documentos XML a los que representa), validación (el parser XML será capaz de comprobar que un documento XML cumple con todas las restricciones expresadas en un schema) o automatización del procesado de documentos XML (los schemas permiten conocer la estructura que cabe esperar en un documento y permiten la gestión automática mediante SW de la información contenida). Pero como se avanzaba no existe un único lenguaje de schema estándar, han surgido varios respondiendo a diferentes necesidades expresivas. El proyecto ISO DSDL (Document Schema Definition Language) ( clasifica estos lenguajes. Lenguajes de schema basados en reglas. Tienen como objetivo describir, a través de reglas, qué requisitos deben cumplir los documentos XML. Ya que cualquier requisito puede ser expresado como un conjunto de reglas de algún tipo, estos lenguajes son los considerados de más bajo nivel o de más granularidad, y el resto podrían ser construidos sobre un lenguaje basado en reglas. Con frecuencia se suelen emplear para complementar a algún otro lenguaje de schema terminando el trabajo que éste no pueda hacer. El ejemplo más conocido de este tipo de lenguaje es Schematron (Jelliffe 2003). Lenguajes de schema basados en gramática. Pretenden describir la estructura de los documentos instancia. Pueden asemejarse al uso que se hace de BNF para describir la sintaxis de los lenguajes de programación. Describen las plantillas a las que se podrán ajustar los nodos XML. Se centran en la estructura y no prestan gran atención a los tipos de datos de la información. Ejemplos: DTD (W3C, 2000), RELAX NG (Clark y Makoto 2001). Lenguajes de schema basados en orientación a objetos. W3C XML Schema (W3C 2001) es algo más que un lenguaje de schema basado en gramática. Es un intento por describir las instancias XML en la forma más cercana posible al diseño orientado a objeto: Pág. B 1

6 Importancia de los tipos de datos. Si elementos y atributos se asimilan a objetos, los tipos son lo más cercano a las clases OO y son la clave para expresar las similitudes entre objetos. Mecanismos de derivación y sustitución. Permiten reflejar la herencia entre clases OO. Además de profundizar en dos de estos lenguajes (XML Schema y Schematron), se van a esbozar las características principales de XSLT como lenguaje especializado en la transformación de documentos XML y se van a repasar algunos proyectos de SW libre directamente relacionados con XML. Pág. B 2

7 B.1.1 XML SCHEMA En este apartado se van a recorrer los aspectos más importantes de los XML Schemas. No pretende ser una descripción exhaustiva, pero sí lo suficientemente profunda como para entender las posibilidades que este lenguaje de schema (define la gramática a emplear para escribir un schema) puede aportar al entorno multidisciplinar. Para completar el conocimiento de XML Schema se recomienda consultar Costello (2003), Van Der Vlist (2002) y W3C (2001). Un XML Schema permite definir una nueva gramática mediante sintaxis XML (a diferencia de su antecesor, el DTD, que utilizaba una sintaxis no XML). Es decir, es una formalización de las restricciones que deben cumplir los documentos XML (denominados instancias) que se asocien a dicho schema. De este modo, un parser XML comprobará que un documento es válido asegurándose de que cumple todas las restricciones recogidas por el schema, o dicho de otra forma, comprobando que está escrito utilizando correctamente la gramática definida en el schema. Define lo único válido, porque todas las instancias deben ajustarse a un único modelo. De este modo, permiten que un conjunto de usuarios o de programas puedan intercambiar automáticamente documentos entre sí, porque para todos es conocida y representada en un schema la estructura y las características de los datos contenidos en los documentos que se van a intercambiar. El Schema constituye la documentación explícita de todo ello y a su vez el mecanismo (con un parser) para asegurar el cumplimiento de esos requisitos en todas las instancias. Los tipos de restricciones que puede recoger un XML Schema son: Estructura en forma de árbol. Sistema de tipos de datos (genéricos, definidos por el usuario, rangos, ). Especificación de tipos de datos y longitudes de datos para la información. Tanto tipos predefinidos como definición de nuevos tipos mediante mecanismos de herencia, subrangos, subtipos o empleando reglas EBNF. Requisitos de cardinalidad. Definición del mínimo y máximo número de ocurrencias para un determinado elemento o atributo. Herencia. Namespaces. Para definir diferentes ámbitos de uso de identificadores evitando colisiones y normalizar el uso de identificadores comunes Agrupación de elementos o atributos por grupos dándoles características comunes. Puede especificarse que sólo deba aparecer uno de los elementos del grupo o que puedan aparecer varios Definición de elementos locales, no todo es global Extensión. Permite la inclusión y/o importación de otros XML Schemas, pudiendo definir nuevas gramáticas a partir de otras ya existentes. Pág. B 3

8 Tabla B Comparación Java / Schema / SQL. Java Schema SQL Clase Tipo Tabla Objeto Elemento Fila B Características básicas En el siguiente ejemplo se define un Schema para una biblioteca, la cual puede contener de uno a infinitos libros los cuales a su vez contienen los elementos título, autor, fecha, ISBN y editorial. </xsd:schema> <xsd:element name="bookstore"> <xsd:complextype> <xsd:sequence> <xsd:element ref="book" minoccurs="1" maxoccurs="unbounded"/> </xsd:sequence> </xsd:complextype> </xsd:element> <xsd:element name="book"> <xsd:complextype> <xsd:sequence> <xsd:element ref="title" minoccurs="1" maxoccurs="1"/> <xsd:element ref="author" minoccurs="1" maxoccurs="1"/> <xsd:element ref="date" minoccurs="1" maxoccurs="1"/> <xsd:element ref="isbn" minoccurs="1" maxoccurs="1"/> <xsd:element ref="publisher" minoccurs="1" maxoccurs="1"/> </xsd:sequence> </xsd:complextype> </xsd:element> <xsd:element name="title" type="xsd:string"/> <xsd:element name="author" type="xsd:string"/> <xsd:element name="date" type="xsd:string"/> <xsd:element name="isbn" type="xsd:string"/> <xsd:element name="publisher" type="xsd:string"/> </xsd:schema> En un schema se declaran los elementos y atributos que podrán ser utilizados como contenedores de información en las instancias. Es decir, todos los datos de un documento XML aparecerán como contenido de un elemento o de un atributo. Además, el schema define componentes que van a ser usados dentro del propio schema, no en la instancia. Se trata de nuevos tipos de datos simples o compuestos. Toda declaración o definición puede ser global, hijo inmediato del elemento <schema>, y por tanto reutilizable en el contexto del schema; o local, cuando el elemento está anidado dentro de otros elementos, y por tanto no puede emplearse en otros puntos del schema. En el ejemplo anterior tanto Book como Title, Author, Data, ISBN y Publisher han sido declaradas como globales y se les puede referenciar desde dentro de otros elementos. Por ejemplo, Bookstore contiene elementos Book, y Book contiene elementos Title, Author, Data, ISBN y Publisher. B Namespace Todos los documentos XML Schema tienen schema como elemento raíz. Sólo puede aparecer una vez y no puede tener ningún elemento por encima ya que se trata del elemento padre. <?xml version="1.0"?> <xsd:schema xmlns:xsd=" Pág. B 4

9 targetnamespace=" xmlns=" elementformdefault="qualified"> Normalmente, este elemento tiene ciertos atributos que hacen referencia al namespace o espacio de nombres. Todo documento XML (incluidos los schemas) deben indicar el namespace que van a emplear. El namespace es el nombre de un vocabulario, el nombre conjunto dado a la serie de elementos y atributos que se van a emplear en el presente documento XML. De este modo, en el ejemplo anterior se usa el prefijo xsd para hacer referencia al namespace al que pertenecen los elementos de XMLSchema. La Figura B muestra el vocabulario básico de todo XML Schema. element complextype sequence schema string boolean integer Figura B Vocabulario asociado al namespace de XML Schema Todo schema puede definir un namespace (utilizando el atributo targetnamespace) para utilizar en sus instancias, es decir, define un vocabulario finito que puede emplearse en las instancias. Además, el namespace definido en un schema también se puede emplear en otros schemas en los que se extienda. targetnamespace El targetnamespace se define como el URI que expresa el espacio de nombres al que pertenecen los componentes (elementos, tipos, etc ) que se definen en un Schema. En el ejemplo se especifica que todos los elementos que se definen en esta gramática pertenecen al espacio de nombres La Figura B. 1-2 muestra el vocabulario definido en el Schema del ejemplo. Pág. B 5

10 BookStore Author Title ISBN Date Publisher xmlns Figura B Vocabulario asociado al namespace Permite definir los prefijos para uno o más espacios de nombres que se usan en un schema. En el ejemplo se define el prefijo xsd para los elementos que pertenecen al namespace de los XML Schemas, dejando el namespace por defecto (sin prefijo) para los elementos que pertenecen al espacio de nombres Normalmente se asigna el prefijo xsd o xs a los elementos que pertenecen al espacio de nombres XML Schema. En el ejemplo todos los elementos que pertenecen al namespace de los XML Schemas levan el prefijo xsd, mientras que los que no llevan prefijo pertenecen al namespace elementformdefault y attributeformdefault Puede tomar los valores qualified o unqualified (valor por defecto). Indica a los documentos XML instancias del schema si es necesario que los elementos o atributos locales aparezcan cualificados cuando no se está utilizando el namespace por defecto (necesario el prefijo). Referenciar un Schema en una instancia A continuación se muestra un ejemplo de una posible instancia válida del Schema ejemplo de partida. <?xml version="1.0"?> <BookStore xmlns =" xmlns:xsi =" xsi:schemalocation =" BookStore.xsd"> <Book> <Title>My Life and Times</Title> <Author>Paul McCartney</Author> <Date>July, 1998</Date> <ISBN> </ISBN> <Publisher>McMillin Publishing</Publisher> </Book> </BookStore> xmlns = le indica al parser XML a qué namespace deben pertenecer los elementos usados en esta instancia. Pág. B 6

11 xsi:schemalocation =" BookStore.xsd indica que los elementos del namespace están definidos en el Schema BookStore.xsd. xmlns:xsi = indica al parser que los elementos que contengan el prefijo xsi pertenecen a ese namespace que hace referencia a la instancia de un XML Schema. schemalocation= " BookStore.xsd" targetnamespace= " BookStore.xml (instancia) BookStore.xsd (Schema) Figura B Relación entre el documento schema y el documento instancia La Figura B. 1-3 muestra la relación entre el documento Schema y el documento instancia. En el Schema se define el nuevo vocabulario que se va a usar en la instancia. En general, al referenciar un Schema se debe tener en cuenta que: El namespace al cual referencia la instancia debe ser el mismo que el definido en el targetnamespace del Schema. El valor del atributo SchemaLocation es un par de la forma. namespace URI. Para los namespaces referenciados que no sean públicamente conocidos (definidos por el usuario, no predefinidos) se debe indicar con el atributo Schemalocation la URI donde encontrar la gramática que los define (*.xsd). B Elementos Existen varias formas de declarar un elemento: Pág. B 7

12 Inline. Se realiza la declaración a la vez que se realiza la definición del tipo (que no será reutilizable). Ésta sería la forma utilizada en el ejemplo anterior, donde se ha utilizado una definición complextype anónima. Modularmente. Esta opción presenta la ventaja de la reutilización del tipo de elemento. utilizando complextype (contiene otros elementos o atributos). Se define un complextype dándole nombre y luego se declaran elementos instanciando ese tipo. Por ejemplo: <xsd:element name="book" type="bookpublication" maxoccurs="unbounded"/> <xsd:complextype name="bookpublication"> <xsd:sequence> <xsd:element name="title" type="xsd:string"/> <xsd:element name="author" type="xsd:string"/> <xsd:element name="date" type="xsd:string"/> <xsd:element name="isbn" type="xsd:string"/> <xsd:element name="publisher" type="xsd:string"/> </xsd:sequence> </xsd:complextype> utilizando simplextype (restricción de un tipo base). Al definir un elemento se puede especificar aspectos como: la cardinalidad (número de veces que debe aparecer en la instancia) a través de minoccurs y maxoccurs, cuyos valores por defecto son 1. Así, minoccurs=0 indica que un elemento es opcional y maxoccurs=unbounded que pueden aparecer todos los que se deseen. valor fijo o por defecto. Si se le asigna un valor en el documento instancia se puede dejar vacío. ComplexType ó simpletype Se debe definir un elemento de tipo complextype cuando dicho elemento va a contener otros elementos o algún atributo. Se debe definir un elemento de tipo simpletype cuando se quiere crear un nuevo tipo derivado refinando otro tipo ya existente. Algunos de los tipos de datos básicos o primitivos sobre los que se puede definir un nuevo simpletype son los siguientes: String, Boolean, decimal, float, double, duration, datetime, time, date, gyearmonth, gyear, gmonthday, gday, gmonth, hexbinary, base64binary, anyuri, QName, NOTATION. También existen tipos de datos predefinidos derivados de los primitivos: normalizedstring, token, language, IDREFS, ENTITIES, NMTOKEN, NMTOKENS, Name, NCName, ID, IDREF, ENTITY, integer, nonpositiveinteger, negativeinteger, long, int, short, byte, nonnegativeinteger, unsignedlong, unsignedint, unsignedshort, unsignedbyte, positiveinteger. Creación de nuevo simpletype Se puede definir un nuevo tipo de datos a partir de un tipo existente (tipo base) especificando una o más facetas opcionales de ese tipo base. Por ejemplo, si se quiere definir un nuevo tipo a partir del tipo base string se puede definir cualquiera de sus facetas opcionales, estas son: length, minlength, maxlength, pattern, enumeration, whitespace. Pág. B 8

13 A su vez, para definir pattern (patrón a seguir) se pueden utilizar expresiones regulares EBNF. Algunos ejemplos se muestran en la Tabla B. 1-2, junto con posibles instancias válidas para el patrón expresado. Tabla B Ejemplos de expresiones regulares para pattern. Expresión regular Posibles instancias Chapter \d Chapter 1 Chapter \d Chapter 1 a*b [xyz]b a?b a+b [a-c]x [-ac]x [ac-]x [^0-9]x \Dx Chapter\s\d (bla){2} fin (bla\s){2} fin.abc (a b)+x a{1,3}x a{2,}x [a-za-z-[ol]]* \p{ll} \p{n} \p{nd} \p{p} \p{sc} b,ab,aab,aaab... xb,yb,zb ab,b ab,aab,aaab ax,bx,cx -x,ax,cx ax,cx,-x caracter no dígito con x caracter no dígito con x Chapter espacio dígito blabla fin bla bla fin un caracter seguido de abc ax,bx,abx,bax,aax... ax,aax,aaax aax,aaax,aaaax cadena sin I ni O una letra minúscula un número un dígito un símbolo de puntuación un símbolo especial En el siguiente ejemplo se define un nuevo tipo de datos simple a partir del tipo base string para describir las características de los números de teléfono: <xsd:simpletype name="telephonenumber"> <xsd:restriction base="xsd:string"> <xsd:length value="8"/> <xsd:pattern value="\d{3}-\d{4}"/> </xsd:restriction> Pág. B 9

14 </xsd:simpletype> Según se ha definido, deben cumplirse todas las facetas de la restricción, es decir sería el equivalente a un AND. Primero se define la longitud de la cadena que debe ser 8 y luego se define el patrón que debe seguir (3 dígitos guión 4 dígitos). En general, varias facetas pattern enumeration restringen en forma de OR. El resto en forma de AND. El tipo de datos integer puede poseer las siguientes facetas: totaldigits, pattern, whitespace, enumeration, maxinclusive, maxexclusive, mininclusive, minexclusive. No es necesario que el tipo base sea uno predefinido, también se pueden crear nuevos tipos de datos simples tomando como base otros tipos simples de datos previamente creados. derivedtypes Se puede hacer una subclasificación dentro de los elementos complextypes que se denomina derivedtypes. Se pueden crear de dos formas: derivación por extensión: añadir nuevos elementos al complextype de partida. Cuando se deriva un elemento por extensión no es necesario repetir los elementos que contiene el tipo base, sino sólo añadir aquellos nuevos. derivación por restricción: definir un subconjunto del tipo base. Es necesario repetir los elementos que contiene el tipo base ya se haga alguna modificación o no, aquellos elementos que no se repiten se considerará que no forman parte del nuevo tipo de datos. A su vez, se puede definir este subconjunto de dos maneras: redefinir un elemento del tipo base para que tenga un rango reducido de valores. redefinir un elemento del tipo base para reducir el número de apariciones. También se puede prohibir la derivación de un tipo de datos, o permitir sólo la derivación por restricción o por extensión. Elementos especiales (<annotation>) El elemento <annotation> se usa para documentar el Schema, tanto para personas como para programas. Para cada caso presenta diferentes elementos hijo: <documentation> para documentación dirigida a personas, este a su vez puede tener dos atributos source contiene el URL de un archivo que contiene más información complementaria lang especifica el lenguaje en el que está escrita la documentación <xsd:documentation source= xml:lang="fr"/> <appinfo> para documentación dirigida a programas, este a su vez puede tener un atributo: source contiene el URL de un archivo que contiene más información complementaria Pág. B 10

15 <xsd:appinfo source=" Las anotaciones no tienen efecto en la validación del Schema, pudiendo ser cualquiera siempre que estén bien formadas en XML. Pero no se pueden poner en cualquier parte del documento, pueden ir antes o después de cualquier componente global. B Atributos Dentro de los elementos se pueden definir atributos que caracterizan al elemento que los contiene. Los atributos no pueden contener otros elementos, es por ello que siempre contendrán tipos simples. Al igual que ocurría con los elementos, los atributos se pueden definier inline o de forma modular, tal y como muestan los siguientes ejemplos: <xsd:attribute name="name" type="simple-type" use="how-its-used" default/fixed="value"/> <xsd:attribute name="name" use="how-its-used" default/fixed="value"> <xsd:simpletype> <xsd:restriction base="simple-type"> <xsd:facet value="value"/> </xsd:restriction> </xsd:simpletype> </xsd:attribute> Use sólo se debe usar cuando se está declarando un atributo localmente a un elemento, no en la declaración global de atributos. Los valores que puede tomar use son: required, optional (sólo en este caso se puede definir un valor por defecto o fijo) y prohibited. En el siguiente ejemplo, en la primera declaración del atributo se define su uso como requerido en todas las instancias porque se está haciendo referencia al elemento libro, sin embargo en la definición global del atributo (más abajo) no se añade use. <xsd:element name="book"> <xsd:complextype> <xsd:sequence> </xsd:sequence> <xsd:attribute ref="category" use="required"/> </xsd:complextype> </xsd:element> <xsd:attribute name="category"> <xsd:simpletype> <xsd:restriction base="xsd:string"> <xsd:enumeration value="autobiography"/> <xsd:enumeration value="fiction"/> <xsd:enumeration value="non-fiction"/> </xsd:restriction> </xsd:simpletype> </xsd:attribute> Algunas consideraciones que hay que tener en cuenta a la hora de definir atributos son: La declaración de atributos siempre se hace al final, después de la declaración de los elementos. Pág. B 11

16 Los atributos hacen referencia siempre al elemento en el que se han definido. Elementos con contenido simple y atributos Imagínese que se quiere definir un Schema para la siguiente instancia: <elevation units="feet">5440</elevation> El elemento elevation tiene dos restricciones, por un lado tiene un contenido simple (integer) y también contiene un atributo denominado units. Como tiene un atributo se debe definir como complextype, pero como no contiene elementos se dice que contiene simplecontent. Entonces, se debe extender este simplecontent para que contenga un atributo. El Schema quedaría de la siguiente forma: <xsd:element name="elevation"> <xsd:complextype> <xsd:simplecontent> <xsd:extension base="xsd:integer"> <xsd:attribute name="units" type="xsd:string" use="required"/> </xsd:extension> </xsd:simplecontent> </xsd:complextype> </xsd:element> Este mismo ejemplo se puede hacer más restrictivo, para ello se restringe el valor de integer entre 0 y y el valor de string para que solo pueda tomar los valores meters o feets. <xsd:simpletype name="elevationtype"> <xsd:restriction base="xsd:integer"> <xsd:mininclusive value="0"/> <xsd:maxinclusive value="12000"/> </xsd:restriction> </xsd:simpletype> <xsd:simpletype name="unitstype"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="feet"/> <xsd:enumeration value="meters"/> </xsd:restriction> </xsd:simpletype> <xsd:element name="elevation"> <xsd:complextype> <xsd:simplecontent> <xsd:extension base="elevationtype"> <xsd:attribute name="units" type="unitstype" use="required"/> </xsd:extension> </xsd:simplecontent> </xsd:complextype> </xsd:element> Se debe utilizar complexcontent cuando se extiende o se hace una restricción sobre un complextype. Se debe utilizar simplecontent cuando se extiende o se hace una restricción sobre un simpletype. B Características específicas Alternativas Si en un Schema se desea que un elemento solo pueda ser una de las opciones, esto es, una or exclusiva, se utiliza choice. En el siguiente ejemplo se define el elemento transportation que sólo puede tomar uno de los siguientes valores: train, plane o automobile. Pág. B 12

17 <?xml version="1.0" encoding="utf-8"?> <xsd:schema xmlns:xsd=" targetnamespace=" xmlns=" elementformdefault="qualified"> <xsd:element name="transportation"> <xsd:complextype> <xsd:choice> <xsd:element name="train" type="xsd:string"/> <xsd:element name="plane" type="xsd:string"/> <xsd:element name="automobile" type="xsd:string"/> </xsd:choice> </xsd:complextype> </xsd:element> </xsd:schema> También se puede añadir cardinalidad: <xsd:choice minoccurs="0" maxoccurs="unbounded"> Orden aleatorio Hasta ahora cuando se utilizaba sequence se tenían que definir los elementos en el mismo orden que en el Schema. Si se desea que aparezcan todos los elementos que se han definido dentro de otro elemento pero no importa el orden se utiliza all. Elemento vacío Se pude definir un elemento vacío que sólo contenga un atributo, así en el siguiente ejemplo se define un elemento imagen que solo contiene un atributo, su dirección. <xsd:element name="image" maxoccurs="unbounded"> <xsd:complextype> <xsd:attribute name="href" type="xsd:anyuri" use="required"/> </xsd:complextype> </xsd:element> La siguiente instancia XML es valida contra el schema anterior: <image href=" Listas Supongamos que se desea declarar un elemento que pueda contener una lista de números enteros, para por ejemplo, definir el elemento número de lotería. (<numbers>) En ocasiones interesa declarar elementos que contengan una lista de valores. Estos son algunos aspectos a tener en cuenta: No se puede crear una lista de listas No se puede crear una lista de complextypes (las listas sólo se aplican a simpletypes) En el documento instancia se debe separar cada componente de la lista con un espacio en blanco (espacio, tabulador o retorno de carro) Sólo se pueden usar las siguientes facetas al crear un tipo lista: Length, minlength, maxlength, enumeration, pattern. Elemento <any> Pág. B 13

18 Este elemento permite al autor del documento instancia extender dicho documento con elementos que no están declarados en el Schema. <xsd:element name="book"> <xsd:complextype> <xsd:sequence> <xsd:element name="title" type="xsd:string"/> <xsd:element name="author" type="xsd:string"/> <xsd:element name="date" type="xsd:string"/> <xsd:element name="isbn" type="xsd:string"/> <xsd:element name="publisher" type="xsd:string"/> <xsd:any minoccurs="0"/> </xsd:sequence> </xsd:complextype> </xsd:element> Ahora en la instancia se puede extender el contenido del elemento <book> con cualquier elemento después de rellenar el elemento <Publisher>. En el siguiente ejemplo se extiende el elemento <Book> con un elemento proveniente de otro Schema: <?xml version="1.0"?> <BookStore xmlns=" xmlns:xsi=" xsi:schemalocation= " BookRetailers.org BookSeller.xsd repository.org SchemaRepository.xsd"> <Book> <Title>My Life and Times</Title> <Author>Paul McCartney</Author> <Date>1998</Date> <ISBN> </ISBN> <Publisher>McMillin Publishing</Publisher> <Reviewer xmlns=" <Name> <First>Roger</First> <Last>Costello</Last> </Name> </Reviewer> </Book> <Book> <Title>Illusions: The Adventures of a Reluctant Messiah</Title> <Author>Richard Bach</Author> <Date>1977</Date> <ISBN> </ISBN> <Publisher>Dell Publishing Co.</Publisher> </Book> </BookStore> AnyAttribute El elemento <anyattribute> permite extender el documento instancia con atributos no definidos en el Schema. Ejemplo: <xsd:element name="book"> <xsd:complextype> <xsd:sequence> <xsd:element name="title" type="xsd:string"/> <xsd:element name="author" type="xsd:string"/> <xsd:element name="date" type="xsd:string"/> <xsd:element name="isbn" type="xsd:string"/> <xsd:element name="publisher" type="xsd:string"/> <xsd:any minoccurs="0"/> </xsd:sequence> <xsd:anyattribute/> </xsd:complextype> Pág. B 14

19 </xsd:element> Ahora se puede añadir atributos en el documento instancia al elemento <Book>. Especificar el namespace del elemento (o atributo) añadido Existen las siguientes opciones: Permitir al documento instancia contener un nuevo elemento con namespace diferente del Schema al que pertenece la instancia: <any namespace="##other"/> Permitir un nuevo elemento que provenga del namespace especificado (se puede especificar una lista de namespaces): <any namespace=" Permite un nuevo elemento proporcionado por el namespace que el Schema está definiendo: <any namespace="##targetnamespace"/> Permite un elemento de cualquier namespace (opción por defecto): <any namespace="##any"/> El nuevo elemento no debe provenir de ningún namespace: <any namespace="##local"/> Contenido abierto Los Schemas que posen los elementos <any> o <any Attribute> se denominan abiertos o extensibles ya que permiten aumentar el contenido de las instancias. Esto es necesario porque es muy difícil contemplar todos los elementos que se van a necesitar desde el diseño. Por el contrario se les denomina estáticos al resto de los schemas. B Trabajo con varios Schemas Aplicar varios Schemas a una misma instancia Una instancia puede estar compuesta por elementos de varios Schemas. Se puede aplicar la validación de un Schema sobre un documento entero o sobre elementos concretos del mismo. En el siguiente ejemplo se ve una instancia en la que se definen dos Schemas, uno para aplicar a los documentos book y otro a los elementos employee: <?xml version="1.0"?> <Library xmlns:xsi=" xsi:schemalocation= " Book.xsd Employee.xsd"> <Books> <Book xmlns=" <Title>My Life and Times</Title> <Author>Paul McCartney</Author> <Date>1998</Date> <ISBN> </ISBN> <Publisher>Macmillan Publishing</Publisher> </Book> <Book xmlns=" <Title>Illusions: The Adventures of a Reluctant Messiah</Title> <Author>Richard Bach</Author> Pág. B 15

20 <Date>1977</Date> <ISBN> </ISBN> <Publisher>Dell Publishing Co.</Publisher> </Book> </Books> <Employees> <Employee xmlns=" <Name>John Doe</Name> <SSN> </SSN> </Employee> <Employee xmlns=" <Name>Sally Smith</Name> <SSN> </SSN> </Employee> </Employees> </Library> Incluir Schemas dentro de otros Schemas El elemento include permite incluir Schemas. Al incluir otros Schemas se debe de tener en cuenta que: Todos los Schemas a incluir deben tener el mismo namespace que nuestro Schema de trabajo. El resultado que se obtiene es el mismo que si se hubieran escrito todas las restricciones en nuestro Schema de trabajo. Si uno de los Schemas incluidos no tiene declarado su targetnamespace asimila el del Schema que hizo el include. El elemento import permite importar namespaces. Ejemplo: <xsd:schema > <xsd:import namespace="a" schemalocation="a.xsd"/> <xsd:import namespace="b" schemalocation="b.xsd"/> </xsd:schema> Tanto incluye como import deben ir antes de cualquier definición de tipos o declaración de elementos en un Schema. Pág. B 16

21 B.1.2 XSLT Este apartado recoge las características fundamentales de XSLT con el objetivo de hacer comprender las aportaciones que este lenguaje puede ofrecer al entorno multidisciplinar. Una información más extensa sobre XSLT se puede encontrar en Tidwell (2001) y en W3C (1999). XSLT (XML Stylesheet Language Transformations) es un lenguaje flexible y potente diseñado para transformar un documento XML en otro documento con una estructura distinta. La transformación expresada en XSLT se denomina Hoja de Estilo (stylesheet). El World Wide Web Consortium (W3C) recomienda seguir un proceso modular en la transformación de la información desde un documento XML hasta un determinado formato de presentación. En todo momento se intenta diferenciar el contenido (información pura), la presentación (información sobre el formato) y las instrucciones de transformación. Este proceso se puede dividir en dos etapas: Transformación de la estructura del documento XML original (XSLT). Aquí se efectúan operaciones como selección de datos, agrupamiento de los mismos, ordenación, transformaciones aritméticas, etc. Aplicación de formato al árbol resultante de la transformación (XSL-FO). Se realiza una transformación de la nueva estructura XML al formato de salida (que puede ser HTML, texto plano, SVG, PDF, audio, ). Esta separación modular permite obtener una gran variedad de salidas (adaptadas a diferentes exigencias de usuario, dispositivos, formatos, ) para una misma fuente de información (documento XML de partida). Aún más, como las propias instrucciones de transformación también se encuentran separadas, se habilita la reutilización de las mismas. Aparte de su uso habitual para la separación de contenido y presentación, XSLT se muestra como una potente herramienta para adaptar entre sí los vocabularios de aplicaciones diferentes. Si dos aplicaciones utilizan XML como soporte para la información de entrada y salida, XSLT posibilita la escritura del puente que habilita el intercambio de información. XSLT permite traducir la información de una gramática particular a otra. Una de las grandes ventajas de XSLT es que realiza las transformaciones utilizando un lenguaje declarativo basado en reglas. Se necesita un mecanismo para poder acceder de forma declarativa a partes (nodos o grupos de nodos) de los documentos XML; esta funcionalidad la proporciona XPath (W3C 1999b). XSLT utiliza el lenguaje XPath para seleccionar los nodos sobre los cuales se van a aplicar las reglas definidas en XSLT, y seleccionar fragmentos del árbol origen para incluirlos en el árbol resultado. Todo documento XML tiene una estructura en árbol subyacente. Como ilustra la Figura B. 1-4, al aplicar una transformación XSLT se pasa de una cierta estructura en árbol a otra distinta (es decir, se cambia la gramática para un mismo contenido). Pág. B 17

22 Figura B. 1-4 Cambio de estructura entre dos documentos Un documento XML (que en su conjunto se denominará elemento documento) se representará entonces mediante una estructura en árbol formada por nodos y trayectos de búsqueda (location paths). Se distinguen 7 tipos distintos de nodos en un documento: Nodo raíz: Es único en el documento y se encuentra en la raíz del árbol. Contiene nodos elemento, todas las instrucciones de procesamiento y los comentarios que aparecen en el prólogo y en el final del documento. Nodos elemento: Son los elementos del documento XML. Los nodos secundarios de un nodo elemento pueden ser otros nodos elemento, nodos comentario, nodos instrucción de procesamiento y nodos texto. El nodo raíz es un caso particular de nodo elemento. Nodos atributo: Cada nodo atributo posee un nombre y un valor de cadena. Todo nodo elemento lleva asociado un conjunto de nodos atributo. Nodos de texto: Todo el contenido de caracteres está agrupado en nodos texto. Nodos instrucción de procesamiento: Contiene un nombre y un valor. Nodos comentario: A cada comentario del documento XML le corresponde un nodo comentario. Nodos namespace: Cada elemento lleva asociado un conjunto de namespace (espacio de nombres). Un trayecto de búsqueda proporciona las instrucciones necesarias para poder acceder a cualquier nodo del árbol, es decir, el camino para ir de un nodo a otro. El nodo de partida es el context node (si el trayecto de búsqueda comienza con el símbolo / el context node es el el nodo raíz). Un trayecto de búsqueda devuelve siempre un conjunto de nodos. B Reglas Una transformación XSLT expresa una serie de reglas para transformar una estructura de árbol origen en otra estructura destino. Para cada regla se pueden distinguir dos partes: Patrón (pattern): Identifica el conjunto de nodos del documento origen sobre los cuales va a aplicarse la regla en concreto. Cuerpo: Detalla las operaciones que se van a llevar a cabo sobre dichos nodos. Cada nodo sobre el que se aplica la regla se sustituirá por otro/s en Pág. B 18

23 el documento de salida. El cuerpo indica dicha sustitución. Consta de elementos ó texto. La Figura B. 1-5 muestra la estructura en árbol de un documento XML de entrada y la Figura B. 1-6 la estructura del documento XML de salida. Figura B Árbol XMLde entrada Figura B Árbol XML de salida Hoja de estilo que se aplica para obtener el documento de salida a partir del documento de entrada: <?xml version="1.0" encoding="utf-8"?> <xsl:stylesheet version="1.0" xmlns:xsl=" xmlns:fo=" <xsl:output method="xml"/> <xsl:template match="/persona"> <person> <name> <xsl:value-of select="//nombre"/> </name> <age> <xsl:value-of select="//edad"/> </age> </person> </xsl:template> </xsl:stylesheet> Patrón: la regla se aplica al nodo Persona (se ve en <xsl:template match="/persona">). Cuerpo: Contenido entre los tags <person> y </person>. Se realiza una instrucción <xsl:value-of select="//edad"/> de forma que se toma el contenido del elemento nombre (documento de entrada) y se aplica al Pág. B 19

24 elemento name (documento de salida). Del mismo modo se toma el contenido del elemento edad (documento de entrada) y se aplica al elemento age (documento de salida). B Ejemplos de Hoja de Estilo Se parte de un documento XML similar al que se ha visto en el ejemplo anterior. Esta estructura se corresponde con el siguiente schema: <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" elementformdefault="qualified" attributeformdefault="unqualified"> <xs:element name="persona"> <xs:annotation> <xs:documentation>ejemplo para hoja de estilo</xs:documentation> </xs:annotation> <xs:complextype> <xs:sequence> <xs:element name="nombre" type="xs:string"/> <xs:element name="apellido" type="xs:string"/> </xs:sequence> </xs:complextype> </xs:element> </xs:schema> Una posible instancia XML que se validaría con dicho schema sería: <?xml version="1.0" encoding="utf-8"?> <Persona xmlns:xsi=" xsi:nonamespaceschemalocation="c:\documents and Settings\Alicia\Mis documentos\xmlalicia\persona.xsd"> <Nombre>Alicia</Nombre> <Apellido>Barrilero</Apellido> </Persona> A continuación, se toma dicha instancia XML y se le aplicarán diferentes ejemplos de hojas de estilo para ver los resultados. Con ello se obtendrán diferentes documentos resultado (con diferentes formatos). B Transformación a XML Figura B Procedimiento habitual XSLT La hoja de estilo que se va a aplicar: <?xml version="1.0" encoding="utf-8"?> <xsl:stylesheet version="1.0" xmlns:xsl=" xmlns:fo=" <xsl:output method="xml"/> <xsl:template match="/persona"> <person> <name> <xsl:value-of select="//nombre"/> </name> <secondname> <xsl:value-of select="//apellido"/> Pág. B 20

25 </secondname> </person> </xsl:template> </xsl:stylesheet> La salida que se obtiene es también un documento XML, pero ahora con diferente formato: <?xml version="1.0" encoding="utf-8"?> <person xmlns:fo=" <name>alicia</name> <secondname>barrilero</secondname> </person> Este documento ya no es validable con el mismo schema que el documento de entrada, puesto que no responde a la misma gramática. B Transformación a HTML La hoja de estilo que se va a aplicar en esta ocasión: <?xml version="1.0" encoding="utf-8"?> <xsl:stylesheet version="1.0" xmlns:xsl=" xmlns:fo=" <xsl:output method="html" encoding="iso "/> <xsl:template match="/"> <html> <head> <title>pagina web</title> </head> <body> <h1>pagina de <xsl:value-of select="./persona/nombre"/> <xsl:value-of select="//persona/apellido"/> </h1> </body> </html> </xsl:template> </xsl:stylesheet> La salida que se obtiene es un documento HTML. B Transformación a texto plano En este caso, la hoja de estilo que se aplica: <?xml version="1.0" encoding="utf-8"?> <xsl:stylesheet version="1.0" xmlns:xsl=" xmlns:fo=" <xsl:output method="text"/> <xsl:template match="/"> <xsl:text>pagina de </xsl:text> <xsl:value-of select="./persona/nombre"/> <xsl:value-of select="//persona/apellido"/> </xsl:template> </xsl:stylesheet> Con ello se obtiene una salida puramente de texto. Pág. B 21

26 B EXSLT EXSLT proporciona librerías de elementos y de funciones para hojas de estilo realizadas por particulares. Todas esas librerías son de libre distribución y se pueden encontrar en Muchas de esas extensiones pueden ser interesantes. Aparecen organizadas según los siguientes módulos: Common: Este módulo comprende elementos y funciones básicas Math: Elementos y funciones que proveen de facilidades para tareas matemáticas Sets: Para conjuntos de nodos Functions: Para definir funciones propias de usuario que se puedan emplear en expresiones y patrones XSLT. Dates and Times: Funciones y elementos relativos a fechas y tiempo. Strings: Para manipulación de cadenas de caracteres Dynamic: Elementos y funciones readicionados con la evaluación dinámica de expresiones XPath. Random: Aleatoriedad B XSL-FO XSL-FO son las siglas de Extensible Stylesheet Language Formatting Objects. Este lenguaje XML se utiliza para describir el formato en el que los datos XML son presentados en pantalla, en papel o en otros medios. Por este motivo está especializado en definir características tales como: tipo de fuente, márgenes, espaciado, bordes, tipo de justificación, tablas, listas, Estructura básica de un documento XSL-FO: <?xml version="1.0" encoding="iso "?> <fo:root xmlns:fo=" <fo:layout-master-set> <fo:simple-page-master master-name="a4"> <!-- Page template goes here --> </fo:simple-page-master> </fo:layout-master-set> <fo:page-sequence master-name="a4"> <!-- Page content goes here --> </fo:page-sequence> </fo:root> Como todo documento XML se empieza siempre por la declaración XML, seguido del elemento raíz <fo:root> con el namespace correspondiente. El elemento <fo:layout-master-set> contiene los distintos templates de las páginas. Estos templates son los elementos <fo:simple-page-master>, cada template debe tener un nombre único (master-name). Estos elementos definen el formato de la página y pueden tener los siguientes atributos: Pág. B 22

27 page-width, page-height, margin-top, margin-bottom, margin-left, margin-right, margin (define los cuatro márgenes). Para acabar de definir la estructura de las páginas (ya se ha especificado tamaño y margenes) se utiliza el elemento <fo:region> el cual especifica los tamaños del encabezado, pie de página y barras laterales. A continuación, un template que definiendo completamente la apariencia de una página: <fo:simple-page-master master-name="a4" page-width= "297mm" page-height= "210mm" margin-top= "1cm" margin-bottom="1cm" margin-left="1cm" margin-right= "1cm"> <fo:region-body margin="3cm"/> <fo:region-before extent="2cm"/> <fo:region-after extent="2cm"/> <fo:region-start extent="2cm"/> <fo:region-end extent="2cm"/> </fo:simple-page-master> Hasta ahora no se ha dicho nada del contenido, sólo nos hemos ocupado de la apariencia. El contenido aparece dentro de los elementos: <fo:page-sequence><fo:flow> CONTENIDO <fo:flow/><fo:page-sequence>. El elemento <fo:page-sequence> debe incluir el atributo master-name que hace referencia a uno de los templates definidos, el cual ha especificado el formato de las páginas. Finalmente dentro del elemento <fo:flow> se utilizan bloques <fo:block>, tablas <fo:table-and-caption> y listas <fo:list-block>. Los bloques admiten atributos como borde (anchura, color), tipo de fuente, color de fondo, alineación del texto, Las tablas son similares a las tablas HTML, se especifican las dimensiones de las celdas y pueden contener bloques o incluso otras tablas. Pág. B 23

28 B.1.3 SCHEMATRON El Schematron es un lenguaje de schema XML creado por Rick Jelliffe (Jelliffe 2003) en la Academia Sinica Computer Center (Taiwan). Se dice que es un lenguaje de schema de restricción abierta porque define un conjunto de reglas a cumplir, pero no un modelo completo para las instancias, define lo que está prohibido y permite el resto. A diferencia de los schemas, que comprueban que una instancia XML se ajuste a una cierta gramática (énfasis en léxico, sintaxis y sistemas de tipos), Schematron está enfocado a la validación de contenidos (comprobación de restricciones sobre los valores y las relaciones entre los datos). Las ventajas del Schematron frente a otros lenguajes de schema estriban en que proporciona herramientas poderosas de validación empleando una sintaxis simple para la implementación. Del mismo modo que XSLT, Schematron se apoya absolutamente en los conceptos de árboles, nodos y trayectos de búsqueda de XPath. Por ese motivo se seguirán haciendo uso de las expresiones, funciones y sentencias XPath. En principio la validación de contenidos se puede hacer mediante hojas de estilo; sin embargo, el uso de schematrones aporta la posibilidad de generación dinámica de esas hojas de estilo con un lenguaje mucho más sencillo, ahí radica su potencia. B Utilidad y Funcionamiento El objetivo fundamental de un Schematron es que sirva como validador de contenidos. A continuación se plantea un ejemplo sencillo de validación de contenidos mediante el uso de una hoja de estilo: <?xml version="1.0" encoding="utf-8"?> <xsl:stylesheet version="1.0" xmlns:xsl=" xmlns:fo=" <!-- Seleccionamos todos los elementos casa--> <xsl:template match="//house"> <!-- Miramos si los elementos casa tienen elementos pared--> <xsl:if test="not(pared)"> La casa no tiene paredes <xsl:if> </xsl:template> </xsl:stylesheet> El resultado de aplicar esta hoja de estilo a un documento XML es que si en el documento aparece algún elemento casa que no contiene elementos pared se saca un mensaje de error indicándolo. Este ejemplo ilustra cómo se puede utilizar una hoja de estilo XSLT con propósitos de validación de contenidos, pero el lenguaje Schematron supone un nivel de abstracción adicional. Se crea un documento schematron utilizando este lenguaje, de modo que, al trasformar ese documento mediante una meta-hoja de estilo (hoja de estilo que genera otras hojas de estilo), se genera la hoja de estilo final que sirve como un validador similar al del ejemplo (Ver Figura B. 1-8). Pág. B 24

29 Figura B. 1-8 Procedimiento general de uso Schematron. En el documento schematron es donde se especifican las reglas que han de ser validadas, es decir, los campos que hay que comprobar y las acciones que hay que tomar en cada caso. El documento schematron se escribe en un lenguaje específico, por tanto, debe ajustarse a una cierta gramática (un cierto schema) que se explica detalladamente en el siguiente apartado. Para obtener el validador se debe aplicar una meta-hoja de estilo (Skeleton) al documento schematron donde están especificadas las reglas a validar. Finalmente, el documento validador se aplica a una cierta instancia XML y sirve para comprobar si dicha instancia cumple las reglas especificadas previamente. La idea más importante es que mediante el schematron se está generando dinámicamente una hoja de estilo para la validación de contenidos. B El Schematron schema Como se acaba de comentar, un documento schematron debe ajustarse a una cierta gramática, a un cierto schema (el schematron schema). El elemento raíz de un schematron schema es un elemento que se denominará schema cuyo namespace es La Figura B. 1-9 presenta la estructura en árbol del schematron schema. Sólo se muestran algunas de las ramas básicas y no la estructura completa. A lo largo del apartado se explicarán todos los aspectos fundamentales de la estructura. Pág. B 25

30 Figura B Schematron Schema. Un documento schematron consiste en una serie de aseveraciones, que pueden cumplirse o no. Para especificar dichas aseveraciones se usan los dos elementos fundamentales del schematron schema: los elementos assert y report. El primero se emplea para aseveraciones que se espera que sean verdaderas, mientras que el segundo se emplea para el caso contrario. Mediante estos dos elementos se construyen las sentencias XPath que más adelante se validarán. Por ejemplo: <assert test="count (paredes) = 4">La casa no tiene 4 paredes</assert> Si no se cumple lo que se testea, la aseveración falla y se muestra al usuario el mensaje La casa no tiene 4 paredes. <report test="count (paredes)">la casa tiene 4 paredes</report> En este caso, sin embargo, se muestra el mensaje en caso de que sí se cumpla la aseveración. Dado que ambos elementos son inversos parece que haya una cierta redundancia. Sin embargo, se emplean ambos porque se usan con distinta intención. En general se suele emplear assert para denotar que se ha producido algún error, mientras que report se suele usar para remarcar alguna característica importante de algún dato en concreto. Los mensajes que se presentan con assert y report son sólo declaraciones escuetas y concretas, pero si se desea añadir más información se puede usar diagnostics. Son elementos que permiten incluir datos adicionales, que se denominará información de diagnóstico. Por ejemplo: <assert test="count(walls) = 4" diagnostics="1">la casa no tiene 4 paredes </assert> <diagnostics> <diagnostic id="1"> Es muy extraño que una casa tenga más o menos de 4 paredes. Pongase en contacto con su arquitecto </diagnostic> </diagnostics> Pág. B 26