Manual de XSL y XML PDF

1 de 137
16 de enero de 2001 www.coverlink.com Manual de XML/XSL

MANUAL
DE
XML/XSL

DOCUMENTACIN COMPLEMENTADA CURSO XML
FECHA CURSO: 11, 12, 13, 14 Y 15 de Diciembre de 2000
Duracin: 25 Horas
Elaboracin manual complementado: Kepa Prez

2 de 137

1. INTRODUCCIN A XML. ............................................................................................................................................. 4
1.1 QU ES EL XML?. ..................................................................................................................................................... 4
1.2. SGML........................................................................................................................................................................... 5
1.3. XML E INTERNET...................................................................................................................................................... 6
1.4. HOJ AS DE ESTILO..................................................................................................................................................... 7
2. SINTAXIS XML. .............................................................................................................................................................. 8
2.1. ESTRUCTURA, MARCA Y CONTENIDO DE UN CONTENIDO XML. ................................................................ 8
2.2. ELEMENTOS Y ATRIBUTOS. .................................................................................................................................. 8
2.3. DOCUMENTOS BIEN FORMADOS......................................................................................................................... 8
2.4. DOCUMENTOS VLIDOS........................................................................................................................................ 9
2.5. DECLARACIN DE TIPO DE DOCUMENTO. ...................................................................................................... 10
2.6. DECLARACIN DE ELEMENTOS......................................................................................................................... 11
2.7. DECLARACIN DE ATRIBUTOS.......................................................................................................................... 13
2.8. COMENTARIOS, PI, SECCIONES CDATA, ENTIDADES PREDEFINIDAS....................................................... 15
2.9. USO DE ENTIDADES. ............................................................................................................................................. 16
3. XSCHEMA. ..................................................................................................................................................................... 20
3.1. QU ES UN ESQUEMA?........................................................................................................................................ 20
3.2. ESTRUCTURA DE UN ESQUEMA......................................................................................................................... 20
3.3. DEFINICIN DE ELEMENTOS. ............................................................................................................................. 22
3.4. UTILIZACIN DE TIPOS DE DATOS PRIMITIVOS............................................................................................. 24
3.5. DEFINICIN DE TIPOS DE DATOS DE USUARIO. ............................................................................................. 25
3.6. EXPRESIONES REGULARES................................................................................................................................. 27
3.7. DERIVACIN........................................................................................................................................................... 29
3.7.1. Derivacin por extensin. ................................................................................................................................... 29
3.7.2. Derivacin por restriccin. ................................................................................................................................. 30
3.8. GLOBALES Y LOCALES......................................................................................................................................... 30
3.9. EQUIVALENCIAS DE ELEMENTOS..................................................................................................................... 30
3.10. DECLARACIN DE ATRIBUTOS........................................................................................................................ 31
3.11. GRUPOS DE ELEMENTOS. .................................................................................................................................. 32
3.12. ELEMENTOS ALTERNATIVOS, REPETITIVOS, ALEATORIOS O VACOS. ................................................. 33
3.12.1. Elementos alternativos. ..................................................................................................................................... 33
3.12.2. Repeticiones. ..................................................................................................................................................... 33
3.12.3. Orden aleatorio................................................................................................................................................. 33
3.12.4. Elementos vacos............................................................................................................................................... 34
3.12.5. Elemento ANY. .................................................................................................................................................. 34
3.12.6. Atributo ANY. .................................................................................................................................................... 34
3.13. DEFINICIN DE CLAVES..................................................................................................................................... 35
4. CASCADING STYLE SHEETS (CSS). ........................................................................................................................ 36
4.1 INTRODUCCIN. ..................................................................................................................................................... 36
4.2. SINTAXIS BSICA.................................................................................................................................................. 37
4.3. SELECTORES........................................................................................................................................................... 38
4.4. HERENCIA. .............................................................................................................................................................. 39
4.5. PROPIEDADES......................................................................................................................................................... 40
4.6. DIV Y SPAN.............................................................................................................................................................. 46
4.7. CASOS ESPECIALES: PSEUDOELEMENTOS Y PSEUDOCLASES. .................................................................. 47
4.8. USO DE DIFERENTES MEDIOS............................................................................................................................. 48
4.9. EJ EMPLO XML CON CSS. ...................................................................................................................................... 49
5. MODELO DE PROCESO DE XSLT............................................................................................................................ 51
5.1. INTRODUCCIN. .................................................................................................................................................... 51
5.2. TEMPLATES............................................................................................................................................................. 53
5.3. CREACIN DE UNA HOJ A DE ESTILO. ............................................................................................................... 55
5.4. XPATH. ..................................................................................................................................................................... 59
5.5. ELEMENTOS XSLT. ................................................................................................................................................ 69
5.5.1. <xsl:sort>........................................................................................................................................................... 69

3 de 137

5.5.2. <xsl:number>..................................................................................................................................................... 69
5.5.3. Bucles.................................................................................................................................................................. 70
5.5.4. Estructuras de decisin. ...................................................................................................................................... 70
5.5.5. Incorporacin de atributos a los elementos. ....................................................................................................... 71
5.5.6. <xsl:variable>.................................................................................................................................................... 72
5.5.7. Comentarios. ....................................................................................................................................................... 73
5.5.8. <xsl:text>............................................................................................................................................................ 73
5.5.9. Scripts. ................................................................................................................................................................ 74
5.6. XML DATA ISLANDS (XML DSO). ....................................................................................................................... 75
5.7. XSL FORMATTING OBJ ECTS (XSL-FO). ............................................................................................................. 76
6. PROCESADORES / PARSERS XML. ......................................................................................................................... 78
6.1. PROCESO DE DOCUMENTOS XML...................................................................................................................... 78
6.2. SIMPLE API PARA XML (SAX). ................................................................................................................................... 78
6.3. DOCUMENT OBJ ECT MODEL (DOM). ......................................................................................................................... 79
ANEXO 1: RECOMENDACIN W3C FEBRERO DE 1998 (CASTELLANO). ........................................................ 80
ANEXO 2: XML SCHEMA W3C WORKING DRAFT MAYO 1999 (INGLS). ..................................................... 111

4 de 137

1. INTRODUCCIN A XML.

1.1 QU ES EL XML?.

XML proporciona a las empresas el camino para el intercambio de informacin. Por eso
stas prefieren los formatos XML a otros porque es ms fcil de interpretar y manipular, se
podra decir que es casi autodescriptivo. De esta forma, si se recibe una cadena de texto normal
sin ninguna identificacin y la tenemos que interpretar, resulta difcil saber qu es exactamente,
pero si ese texto va acompaado de unas etiquetas, s que podemos identificarla (transforma los
datos en informacin descriptiva). Es un meta markup language (metalenguaje de marcas) y es
extensible, ya que no es un formato prefijado como HTML.

XML refuerza el impacto de internet en el mundo empresarial ya que se integran de esta
forma ms rpidamente. Es decir, si queremos modificar la presentacin o contenido de pginas
se requiere menos tiempo y recursos humanos utilizando XML que otro formato.

Es el futuro lenguaje de la Web aunque por ahora no lo sustituir, esto es debido a que los
navegadores actuales nicamente entienden HTML. Existen browsers que dicen entender XML,
aunque en realidad tienen que transformar este lenguaje para poder presentarlo.

El uso de XML elimina la libertad del HTML que es anrquico, y nos presenta el XHTML que
debe seguir unas normas. El eXtensible Markup Language es un estndar desarrollado por el
grupo W3C o World Wide Web Consortium (www.w3.org) para textos estructurados. Este grupo
se dedica a definir estndares en los que las empresas de software se basan posteriormente para
crear sus aplicaciones. Existe otros subgrupos del W3C como es el grupo OASIS que pretende la
estandarizacin de los documentos, y as permitir el intercambio de stos fcilmente, y sin las
complicaciones que se produciran con documentos con diferentes estructuras. Este grupo tiene
ya definido un catlogo de XML con DTD estandarizados, de esta forma las ramas sanitarias
(HL7), qumica/farmacuticas (CML), financieras (VisaXML, IFX, BIPS), del turismo/viajes
(OTA), de la prensa/publicitarias (aXML), etc... puede intercambiarse documentos con un DTD
ya definido y estandarizado, y por tanto sin complicaciones.

Actualmente hay 2 versiones de XML: 1.0 y 1.1, aunque la mayora de los parsers
(procesadores) por ahora slo reconocen la versin 1.0.

5 de 137

El XML separa contenido de estructura, es decir podemos saber si un documento est bien
formado sin saber qu es lo que contiene. Todo elemento del documento tiene un principio y un
final, y entre esas dos etiquetas tendremos el valor del elemento, aunque tambin puede
contener a otros elementos.

<?xml version="1.0" encoding="ISO-8859-1"?>
<informe>
<fecha>24 de diciembre de 2000</fecha>
<hora>14:00</hora>
<area>
<ciudad>Len</ciudad>
<region>Castilla y Len</region>
<pais>Espaa</pais>
</area>
<mediciones>
<cielo>claro</cielo>
<temperatura escala="C">25</temperatura>
<viento>
<direccion>SW</direccion>
<velocidad>6</velocidad>
</viento>
</mediciones>
</informe>

En el ejemplo <area> es un elemento que contiene a otros elementos y <ciudad> es un
elemento que contiene un valor.

1.2. SGML.

XML tiene a SGML (Structured Generalized Markup Language) como predecesor; ste es
un metalenguaje que cumple con el estndar ISO 8879, permite definir diferentes tipos de
documentos y cuyos objetivos son:
- Proceso de documentos por ordenador.
- Separacin de estructura, contenido y presentacin.
- Independencia de sistemas y vendedores.

Es decir, tena las mismas caractersticas que el XML y se utilizaba, pero tena varios
inconvenientes:
- Complejidad.
- Muchas opciones para aplicaciones especiales.
- Sintaxis no legible.
- SGML disea herramientas demasiado complicadas.

Por tanto si al SGML le aadimos internet (antes no estaba preparado para la presentacin
de documentos en internet), y le eliminamos su complejidad y otras caractersticas que le hacen
ilegible, obtenemos el XML.

6 de 137

1.3. XML e INTERNET.

El XML pretende en definitiva que en el mundo de internet, los documentos sean ms
fciles de integrar en esas pginas.

As, otro predecesor del XML es el HTML que se utiliza para la presentacin de la
informacin en internet. ste tiene ventajas aprovechadas por el XML:
- Es el lenguaje de formateo para los navegadores de internet.
- Es fcil de entender y utilizar.
- Su uso es muy extendido.

Pero tiene los inconvenientes que intenta suplir el XML:
- No tiene semntica.
- El contenido no puede ser reconocido ni procesado por programas.
- Tiene un costoso mantenimiento de las pginas.
- No tiene estndares comunes.
- Slo tiene hiperenlaces simples (XML puede tener de 1 a n enlaces).
- Dificultad de ampliacin (razones polticas y tcnicas).

HTML es un lenguaje de marcas fijas. Slo se deben utilizar las marcas establecidas en
las especificacin, y cualquier otra marca es ignorada.
XML sin embargo, permite al diseador crear sus propias marcas, especificando su
sintaxis y funcionalidad de tal forma que las nuevas marcas puedan ser reconocidas e
interpretadas por los visualizadores.
Esto es muy til puesto que las propias marcas pueden ser utilizadas para identificar
contenidos, no slo para determinar la forma de presentacin al usuario como hace HTML.

7 de 137

En resumen, el HTML es un lenguaje muy fcil de comprender y muy utilizado para la
presentacin de la informacin, pero sta no se puede procesar ni almacenar, ya que no permite
ser manipulado por un programa debido a su anarqua (al ser tan libre, es en consecuencia, muy
personal del programador).

1.4. HOJAS DE ESTILO.

Uno de los problemas que puede aparecer es el formato de presentacin, ya que existen
muchas, y muy diversas. Por eso el XML pretende una integracin mucho ms fcil con las
distintas publicaciones. Es decir, una misma estructura nos la permite manipular y procesar de
diferentes formas a travs de un componente que son las hojas de estilo (XSL).

Esto es en cuanto a presentacin, puesto que la tecnologa XML como manipulador de
informacin que es, intenta que esas diferentes comunicaciones utilicen la misma estructura y as
facilitar el intercambio de datos.

8 de 137
2. SINTAXIS XML.

2.1. ESTRUCTURA, MARCA Y CONTENIDO DE UN CONTENIDO XML.

La estructura de un documento XML es un conjunto de etiquetas y su contenido siguiendo
unas normas. Las marcas estn entre los caracteres < y >, y tambin entre </ y >. El
contenido es lo que hay entre las marcas, que pueden ser otras etiquetas.

Podemos distinguir 2 tipos de contenido: elemento y atributo.

2.2. ELEMENTOS Y ATRIBUTOS.

Los elementos poseen su propia etiqueta, mientras que los atributos irn dentro de la
etiqueta de comienzo del elemento al cual pertenecen esos atributos.

Dentro de un documento XML puede haber elementos vacos definidos como tal o porque
no contienen contenido.

<temperatura escala="C"></temperatura>

<temperatura escala="C"/>

En el ejemplo, la primera no tiene contenido y la segunda est definida de esa forma, ya
que lo nico que nos interesara sera el atributo.

2.3. DOCUMENTOS BIEN FORMADOS.

Dentro del XML podemos distinguir documentos vlidos y documentos bien formados. Un
documento est bien formado si se dan las mnimas condiciones para ser manipulados por las
aplicaciones, y para ello se deben cumplir lo siguiente:

9 de 137

Debe aparecer una etiqueta XML con la versin (no es obligario pero s recomendable),
y es muy frecuente encontrarnos adems el atributo encoding que le dir al parser el
formato con el que tiene que interpretar los caracteres del documento. As para poder
entender caracteres espaoles como la o las tildes utilizamos el encoding ISO-8859-
1, ya que por defecto usa UTF-8 UTF-16.

Debe haber una etiqueta de inicio y otra de final por cada elemento del XML, salvo
cuando sea un elemento vaco que puede tener en una sola etiqueta inicio y final:
<temperatura escala="C"/>. Es decir todas las etiquetas deben estar cerradas.

Toda la informacin del documento debe estar agrupada en un elemento principal. Es
decir, todas las etiquetas deben estar dentro de una nica etiqueta que ser el padre
del resto. En el ejemplo anterior , sta sera: <informe>.

Tenemos que tener en cuenta que el XML es case sensitive, es decir distingue las
etiquetas maysculas y minsculas, pues para l son distintas.

El valor de los atributos debe estar siempre entre comillas simples o dobles.

Las etiquetas deben estar bien anidadas, es decir no puede haber elementos solapados.
Por ejemplo, si tenemos 2 elementos y uno contiene al otro, no se puede cerrar antes la
etiqueta del primero que la del segundo; debe cerrarse la marca del elemento contenido
en primer lugar.

Si utilizamos una DTD, las etiquetas no pueden tener un mismo nombre con formatos
diferentes, o sea que marcas iguales estn en diferentes posiciones del documento. Sin embargo
con XSCHEMA s admitira que tuvieran el mismo nombre y los interpretara dependiendo de la
posicin del elemento. Ya veremos los XSCHEMA en el captulo 3.

2.4. DOCUMENTOS VLIDOS.

Para que un documento sea vlido debemos de tener una herramienta que valide a partir
del documento XML y una DTD. Esta herramienta es un procesador o parser, y en el caso de que
no se produzca ningn error genera un rbol del documento (si es un parser de DOM ya se
vers ms adelante).

La DTD (definicin del tipo de documento) es el esquema que debe seguir el documento
para que el procesador al compararlo con el documento en s, pueda saber si ste es vlido o no.

10 de 137

2.5. DECLARACIN DE TIPO DE DOCUMENTO.

Para saber qu DTD utiliza un documento XML se indica en el propio XML de la siguiente
forma <!DOCTYPE nombre del documento SYSTEM nombre.dtd>.

<!DOCTYPE informe SYSTEM "tiempo.dtd">
<informe>
<hora>14:00</hora>
<area>
<ciudad>Len</ciudad>
<region>Castilla y Len</region>
<pais>Espaa</pais>
</area>
<mediciones>
<cielo>claro</cielo>
<temperatura escala="C">25</temperatura>
<viento>
<direccion>SW</direccion>
<velocidad>6</velocidad>
</viento>
</mediciones>
</informe>

Si el nombre de la DTD es un fichero, lo busca en el mismo directorio del documento XML.
Si no est en l se pone la direccin relativa o absoluta para llegar al fichero: <!DOCTYPE
informe SYSTEM "../dtds/tiempo.dtd"> o <!DOCTYPE informe SYSTEM
"c:/xml/dtds/tiempo.dtd">.

Tenemos que tener en cuenta que no puede haber 2 etiquetas DOCTYPE a 2 DTD en un
fichero XML, pero s se puede referenciar una DTD desde otra.

11 de 137

Existe otra forma de referenciar a una DTD, y es con PUBLIC: <!DOCTYPE informe PUBLIC
"tiempo.dtd">. No hay apenas diferencias entre una y otra, ya que con las direcciones absolutas
o relativas encuentra las DTD en los dos casos. Pero cuando unicamente ponemos el nombre de
la DTD, SYSTEM lo busca en el mismo directorio, mientras que PUBLIC lo busca en todo el rbol
de directorios de la mquina.

Pero no slo se puede poner un fichero que est en nuestra mquina, tambin se puede
referenciar una direccin http:

<!DOCTYPE informe SYSTEM "http://123.234.2.34/xml/dtds/tiempo.dtd">

Existen 2 tipos de DTD: externa e interna. La externa, es la que hemos visto antes;
desde el documento XML se referencia a travs de la etiqueta DOCTYPE y SYSTEM o PUBLIC.
La interna est definida dentro del propio XML, y por tanto no tiene ninguna referencia. La
declaracin de la DTD se encuentra en una etiqueta: <!DOCTYPE nombre del documento XML [
y despus se cierra con ]>.

<!DOCTYPE informe [
<!ELEMENT informe (fecha, hora, area, mediciones)>
<!ELEMENT fecha (#PCDATA)>
<!ELEMENT hora (#PCDATA)>
<!ELEMENT area ((ciudad, region, pais) | (x, y))>
.............
]>
<informe>
<hora>14:00</hora>
<area>
.........

2.6. DECLARACIN DE ELEMENTOS.

La declaracin de un elemento es: <!ELEMENT nombre (contenido)>. Donde nombre, es
el elemento que estamos declarando y contenido, lo que va a contener dicho elemento.

El contenido de un elemento pueden ser otros elementos o un valor (cadena de
caracteres). En este ltimo caso se coloca (#PCDATA):

<!ELEMENT pais (#PCDATA)>

La dificultad est cuando contiene a otros elementos, ya que le podemos poner tantas
restricciones como se pueda para que el documento XML sea vlido.

12 de 137

MODELO DE CONTENIDO DE LOS ELEMENTOS:

Cuando un elemento contiene un nico elemento (tenemos que tener en
cuenta que de esta forma debe aparecer una vez, en caso contrario el parser
da error):

<!ELEMENT identidad (dni)>

Cuando aparece una vez o ninguna (se utiliza el carcter ?):

<!ELEMENT telefono (numero?)>

Cuando aparece una o ms veces (se utiliza el carcter +):

<!ELEMENT registro (factura+)>

Cuando aparece cero o ms (se utiliza el carcter *):

<!ELEMENT telefonos (numero*)>

Todos los caracteres anteriores pueden ir junto al elemento al que marcan o fuera
de los parntesis. Teniendo en cuenta que al ir fuera de ellos actuaran sobre todo
lo que contenga. En estos casos como slo contienen un elemento dara lo mismo.

Cuando un elemento contiene una secuencia fija de elementos (deben
aparecer en el mismo orden y una nica vez):


Cuando un elemento contiene una lista de elementos (Es un OR, por lo que
debe aparecer slo uno de ellos):

<!ELEMENT estacion (verano|otono|invierno|primavera)>

Todos los anteriores pueden mezclarse para conseguir lo que se desee:

<!ELEMENT informe (fecha+, hora?, area, mediciones*)>
<!ELEMENT informe (fecha | (hora?) | area | mediciones*)+>
<!ELEMENT informe (((fecha, hora)?) | (area | mediciones)))+>

As por ejemplo, si desea una secuencia de elementos pero que no tenga un
orden fijo (aparecern uno o ms veces cualquiera de ellos: verano y otono;
invierno, verano y primavera...):

<!ELEMENT estacion (verano|otono|invierno|primavera)+>

13 de 137

Tambin puede tener un contenido mixto, es decir caracteres u otros
elementos:

<!ELEMENT contacto (#PCDATA | (email, telefono, direccion))>

Puede que no tenga ningn contenido (se utiliza EMPTY y el elemento siempre
debe estar vaco). Este caso se puede utilizar cuando un elemento tiene
atributos que son los que contienen los valores:

<!ELEMENT vacio (EMPTY)>

O sin condiciones para el contenido (con ANY):
<!ELEMENT libre (ANY)>

2.7. DECLARACIN DE ATRIBUTOS.

Se declaran <!ATTLIST elemento atributo tipo_atributo valor_defecto>. Donde elemento
es el elemento al cual pertenece y atributo es el nombre del atributo.

El tipo de los atributos puede ser:
CDATA: Cuando es una cadena de caracteres.
Una enumeracin de valores que puede tener el atributo: (a|b|c).
ID: Si el valor del atributo es nico en el documento.
IDREF: El valor debe coincidir con el atributo ID del mismo documento o est vaco.

El valor por defecto puede ser:
#REQUIRED: Si es un valor obligatorio.
#IMPLIED: No tiene condiciones, es opcional.
#FIXED VALOR: El atributo debe coincidir con el valor definido como defecto.
Valor por defecto.

Ejemplos:
<!ATTLIST temperatura escala CDATA #IMPLIED>

El atributo escala es una cadena de caracteres
y no es obligatorio, puede que el elemento
temperatura no tenga dicho atributo.

<!ATTLIST temperatura escala CDATA #REQUIRED>

Aqu s es obligatorio.

14 de 137

<!ATTLIST temperatura escala CDATA #FIXED c>

El valor del atributo escala siempre debe valer
c.

<!ATTLIST temperatura escala CDATA c>

Si no tiene ningn valor coge c como
predeterminado.

<!ATTLIST temperatura escala (C|CDATA) #REQUIRED>

Aqu es obligatorio y puede ser C una
cadena de caracteres.

<!ATTLIST coche color (rojo|azul|blanco) #IMPLIED>

No es obligatorio, pero si tiene algn valor
debe ser alguno de estos 3.

<!ATTLIST table align (left|right|center) left>

Este forma parte del DTD que tiene por
defecto el HTML. Vemos que dentro del
elemento table, tiene un atributo align que
puede tener una serie de valores y que por
defecto es left.

<!ATTLIST temperatura escala (R|J) #FIXED "C">

No sera una declaracin correcta, porque le
damos a elegir entre 2 valores (R y J) pero le
decimos que debe ser C. Dara error.

<!ATTLIST empleado cod ID #REQUIRED
jefe IDREF #IMPLIED>

Todos los atributos de un elemento se pueden
poner juntos en una misma declaracin como
vemos en el ejemplo. Aqu cod es obligatorio
y su valor es nico en el documento. El
atributo jefe debe coincidir con el ID, y no es
obligatorio

<empleado cod='1024' jefe='100'/>
<empleado cod='485' jefe='100'/>
<empleado cod='100'/>

Este sera el XML del ejemplo anterior, donde
el empleado con el cod=100 sera el jefe y los
otros dos sus empleados. El empleado con
cod=100 debe existir o dara error en los
atributos jefe de los otros.

A la hora de elegir si utilizar un atributo o un elemento para tener un valor, depende de si
queremos que tenga un valor u otro (utilizamos atributos) o si queremos saber cuanto se repite

15 de 137

(utilizamos elementos). Desde el punto de vista de la programacin es ms sencillo que todos
sean atributos.

Ejemplos de DTD:

La DTD (tiempo.dtd) correspondiente al ejemplo xml ya visto anteriormente:
<!ELEMENT fecha (#PCDATA)>
<!ELEMENT hora (#PCDATA)>
<!ELEMENT area ((ciudad, region, pais) | (x, y))>
<!ELEMENT ciudad (#PCDATA)>
<!ELEMENT region (#PCDATA)>
<!ELEMENT pais (#PCDATA)>
<!ELEMENT x (#PCDATA)>
<!ELEMENT y (#PCDATA)>
<!ELEMENT mediciones ((cielo|temperatura|humedad|visibilidad|viento)+)>
<!ELEMENT cielo (#PCDATA)>
<!ELEMENT temperatura (#PCDATA)>
<!ELEMENT humedad (#PCDATA)>
<!ELEMENT visibilidad (#PCDATA)>
<!ELEMENT viento (direccion,velocidad)>
<!ATTLIST temperatura escala CDATA #REQUIRED>
<!ELEMENT direccion (#PCDATA)>
<!ELEMENT velocidad (#PCDATA)>

Una DTD que permita almacenar diferentes discos que tengamos en nuestra discoteca con
la siguiente informacin: ttulo, intrprete, canciones, casa discogrfica. Teniendo en
cuenta que un disco puede tener muchas canciones con intrpretes diferentes, y que
una cancin puede tener varios intrpretes:

<!ELEMENT discos (disco)*>
<!ELEMENT disco (titulo, ((interprete+,cancion+) | (cancion,interprete+)+), casadisc)>
<!ELEMENT titulo (#PCDATA)>
<!ELEMENT interprete (#PCDATA)>
<!ELEMENT cancion (#PCDATA)>
<!ELEMENT casadisc (#PCDATA)>

2.8. COMENTARIOS, PI, SECCIONES CDATA, ENTIDADES PREDEFINIDAS.

Para hacer comentarios en XML se pone el texto entre las marcas:. Por
ejemplo: .

Las instrucciones de proceso PIs indican al procesador cmo tiene que interpretar las
sentencias. Van entre las marcas <? y ?>.

Un ejemplo: <?xml version="1.0" encoding="ISO-8859-1"?>

16 de 137

Dentro de las secciones CDATA irn todos aquellos caracteres que no queramos que
interprete el procesador.

Nosotros podramos poner <temperatura> <0 </temperatura>?, pues NO, porque el
valor del elemento contiene uno de los caracteres reservados (en este caso <). Otras entidades
predefinidas son:

< <
> >
& &
'
"

El ejemplo anterior sera: <temperatura><![CDATA[ <0 ]]></temperatura>, ya que el
interior de la seccin CDATA, el parser lo interpreta como una cadena de caracteres y la trata
como tal.

Tambin se podra haber puesto <temperatura> <0 </temperatura>, pero de esta forma
hay que ir trasformando todos los caracteres reservados para ser correcto, mientras que con el
CDATA no importa qu caracteres tiene el elemento.

2.9. USO DE ENTIDADES.

Existen dos tipos de entidades de usuario: de sustitucin y de definicin, y ambas se
definen dentro de la DTD.

La entidad de sustitucin se declara <!ENTITY nombre valor>. Donde nombre es la
entidad que est definiendo y valor puede ser una cadena de texto o el contenido de un fichero
(utilizando SYSTEM):

<!ENTITY cov "COVERLINK">
<!ENTITY covtext SYSTEM "http://www.coverlink.com/kepa.txt">

Cuando queramos referenciar estas entidades escribimos &nombre;, y se sustituirn
cuando se represente el documento XML:

<texto>&cov; est orgulloso de anunciar... &covtext;</texto>

17 de 137

Esto es vlido porque las considera cadenas de texto. Ejemplo:

<!DOCTYPE orden-pedido
[
<!ENTITY Cabecera SYSTEM "SeccionCabecera.xml">
<!ENTITY PosicionPC SYSTEM "Posicion/PC1.xml">
<!ENTITY PosicionMonitor SYSTEM "http://monitores.de/m2.xml">
]>

<orden-pedido>
<datos-cliente>&Cabecera;</datos-cliente>
<orden>
<posicion>&PosicionPC;</posicion>
<posicion>&PosicionMonitor;</posicion>
</orden>
</orden-pedido>

La entidad de definicin se declara <!ENTITY % nombre valor>. Estas entidades no son
cadenas de textos, sino definiciones, por lo que no se referencian dentro del XML como las
entidades de susitucin, sino dentro de la DTD.

Se referencia con %nombre;:

<!DOCTYPE ejemplo
[
<!ENTITY % entidad-ejemplo "<!ELEMENT ejemplo(#PCDATA)>">
%entidad-ejemplo;
]>
<ejemplo>
Aqu viene cualquier cosa
</ejemplo>

Las entidades de definicin pueden tener parmetros internos y externos:

PARMETROS INTERNOS DE LAS ENTIDADES

Aqu definimos la entidad bloque que puede
ser parrafo listado imagen. Posteriormente
se referencia en la definicin de otros
elementos de la DTD.
<!ENTITY % bloque "parrafo | listado | imagen">

<!ELEMENT libro (capitulo+)>
<!ELEMENT capitulo (titulo, (%bloque;)*, seccion+)>
<!ELEMENT seccion (titulo, (%bloque;)*, subseccion*)>
<!ELEMENT subseccion (titulo, (%bloque;)+)>
<!ELEMENT parrafo (#PCDATA)>
...

PARMETROS EXTERNOS DE LAS ENTIDADES

Estamos referenciando desde esta DTD a otra
externa (tabla-modelo.dtd). Es decir, todo lo
que haya en esa DTD externa lo voy a tener
disponible.
<!ENTITY % tabla-modelo SYSTEM "tabla-modelo.dtd">

%tabla-modelo;

<!ENTITY % bloque "parrafo | listado | imagen |tabla">

<!ELEMENT libro (capitulo+)>
<!ELEMENT capitulo (titulo, (%bloque;)*, seccion+)>
<!ELEMENT seccion (titulo, (%bloque;)*, subseccion*)>
<!ELEMENT subseccion (titulo, (%bloque;)+)>
<!ELEMENT parrafo (#PCDATA)>
...

18 de 137

Otra de las caractersticas del uso de entidades es la integracin de datos no XML. Esto
se entiende mejor con un ejemplo:

Primero definimos un elemento logo que
estar vaco pero con un atributo imagen
que es de tipo ENTITY y es obligatorio. Con
NOTATION le defino un nombre (GIF) para
que sea interpretado por un ejecutable
(gifmagic.exe). Definimos la entidad
kepalogo, le decimos donde est (con
SYSTEM) y con NDATA le indicamos con
qu ejecutable queremos que lo interprete.
<!ELEMENT logo EMPTY>

<!ATTLIST logo imagen ENTITY #REQUIRED>

<!NOTATION GIF SYSTEM "gifmagic.exe">

<!ENTITY kepalogo SYSTEM "http://www.coverlink.com/logo1.gif" NDATA GIF>
...
<logo imagen="&kepalogo;"/>

19 de 137

20 de 137

3. XSCHEMA.

3.1. QU ES UN ESQUEMA?

El lenguaje de esquema nos permite definir estructuras de documentos XML de la misma
forma que las DTDs, aunque a diferencia de stas, el lenguaje que se utiliza es ms complejo.
Por qu se utilizan los xschemas?:

Posibilitan la utilizacin de diferentes tipos de datos. Con las DTD solo existan un tipo
de datos.

Posibilitan la creacin de tipos de datos propios.

Posibilitan la definicin de modelos de contenido.

Tiene la misma sintaxis que un documento XML. En realidad, un esquema es un
documento XML vlido, por lo que necesitamos un procesador para validarlo.

Es posible definir elementos con el mismo nombre pero con diferentes contenidos.

Es posible definir la unicidad de un elemento.

Etc.

3.2. ESTRUCTURA DE UN ESQUEMA.

Lo primero que tenemos que tener en cuenta es que el XSCHEMA no es estndar, sino que
estn en working draft del W3C. Es decir, todava se est trabajando en l y puede que se
produzcan cambios respecto a lo que hay ahora. Por eso, es frecuente encontrarnos algunos
editores o parseadores que utilizan otras versiones diferentes a la propuesta por el W3C.

Un esquema se define entre las etiquetas <schema> y </schema>, y dentro de ellas
tendremos referencias a namespaces espacios de nombres. Un namespace es un fichero que
contiene la definicin de etiquetas y mtodos que se van a utilizar en el documento. Es parecido
a una DTD pero con una sintaxis diferente, ya que cuando se encuentra un elemento, para
validarlo, accede a este fichero y as lo reconoce.

21 de 137

<?xml version="1.0"?>
<schema xmlns="http://www.w3.org/1999/XMLSchema"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/1999/XMLSchema
http://www.w3.org/1999/XMLSchema.xsd"
targetNamespace="http://www.publishing.org/namespaces/CatalogoLibros"
elementFormDefault="qualified"
xmlns:cat="http://www.publishing.org/namespaces/CatalogoLibros">

<element name="CatalogoLibros">
<complexType>
<sequence>
<annotation>
<documentation>
Un catlogo de libros contiene cero o ms libros
</documentation>
</annotation>
<element ref="cat:Libro" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>

<element name="Libro">
<complexType>
<sequence>
<element ref="cat:Titulo" minOccurs="1" maxOccurs="1"/>
<element ref="cat:Autor" minOccurs="1" maxOccurs="1"/>
<element ref="cat:Fecha" minOccurs="1" maxOccurs="1"/>
<element ref="cat:ISBN" minOccurs="1" maxOccurs="1"/>
<element ref="cat:Editorial" minOccurs="1" maxOccurs="1"/>
</sequence>
</complexType>
</element>

<element name="Titulo" type="string"/>
<element name="Autor" type="string"/>
<element name="Fecha" type="string"/>
<element name="ISBN" type="string"/>
<element name="Editorial" type="string"/>
</schema>

Este ejemplo as visto, puede parecer difcil de entender sobre todo con las referencias a los
namespaces, ya que hace alusin a 2 namespace diferentes, adems de crear uno propio.

La referencia a los namespaces se hace con el atributo xmlns. Si tenemos este atributo sin
la definicin del prefijo para los elementos, entonces estamos con el namespace por defecto:
xmlns="http://www.w3.org/1999/XMLSchema". As, cuando nos encontremos con algn
elemento que no tenga prefijo por delante, para comprobarlo, lo va a buscar a este namespace.
Aunque el namespace es una direccin web, no accede a internet, sino que es la forma que
existe para indicarle al procesador cual se est utilizando y validar el documento.

En cambio, si tenemos el atributo xmlns con algun prefijo despus de dos puntos, le
indicamos que si encuentra alguna etiqueta con esta identificacin previa, lo vaya a buscar a este
namespace y no al que tiene por defecto o a otros que se estn referenciando.

Ejemplos:

22 de 137

xmlns:cat="http://www.publishing.org/namespaces/CatalogoLibros".

Si en el documento encontrara algn elemento con el prefijo xsi: (<xsi:ejemplo>) lo ira a
buscar al primer namespace y si encuentra otro con cat: (<cat:otroejemplo>) lo intenta validar con
el segundo.

La referencia al segundo namespace (xmlns:xsi), en el ejemplo se ha hecho en dos pasos:
primero referencia a XMLSchema-instance, que valida a los otros dos esquemas referenciados
por el segundo con xsi:schemaLocation, XMLSchema y XMLSchema.xsd. Aunque esto depende
del parser o procesador con el que trabajemos, en otros slo exige la primera referencia.

Para la creacin de un namespace propio lo hacemos con el atributo targetNamespace:
targetNamespace="http://www.publishing.org/namespaces/CatalogoLibros". Esto genera un fichero .xsd que
ser el esquema, pero para hacerlo correctamente, la definicin de dicho esquema debe ser
validada por el procesador. Con la sentencia: elementFormDefault="qualified" le decimos que queremos
calificarlo, es decir, que los elementos del esquema llevara un prefijo por delante para
identificarlos (el calificador es cat:). Tenemos que tener en cuenta que en muchos procesadores,
la creacin de un nuevo namespace nos devuelve un error, y esto es porque est en working
draftk por el W3C.

La referencia a un namespace dentro de un documento XML sera:
<CatalogoLibros xmlns="http://www.publishing.org/namespaces/CatalogoLibros">
<Libro>
<Titulo>Solsticio de invierno</Titulo>
<Autor>Rosamunde Pilcher</Autor>
<Fecha>julio, 2000</Fecha>
<ISBN>840132839X</ISBN>
<Editorial>Plaza & Jans</Editorial>
</Libro>
...
</CatalogoLibros>

3.3. DEFINICIN DE ELEMENTOS.

Cuando se van a definir los esquemas tenemos que tener en cuenta que el nombre del
primer elemento debe coincidir con el nombre del namespace. Para definir elementos de un
esquema se utiliza la etiqueta <element> con los siguientes atributos posibles:

name: Indica el nombre del elemento. Es obligatorio.
type: Seala el tipo.
ref: Referencia a un elemento que se definir en otra parte del documento.

23 de 137

minOccurs: Mnima ocurrencia del elemento. Puede ser un nmero o unbounded
(infinito).
maxOccurs: Mxima ocurrencia del elemento. Puede ser un nmero o unbounded
(infinito).

Un elemento puede ser de tipo complejo y estar formado por otros elementos ms simples:

....
<element name="empleado">
<complexType>
<sequence>
<element ref="emp:Nombre" minOccurs="1" maxOccurs="1"/>
<element ref="emp:Apellido" minOccurs="1" maxOccurs="1"/>
<element ref="emp:DNI" minOccurs="1" maxOccurs="1"/>
<element ref="emp:Salario" minOccurs="1" maxOccurs="1"/>
</sequence>
</complexType>
</element>
....
....
<element name="Nombre" type="string"/>
(Definicin del elemento Nombre referenciado
antes dentro de la definicin de Empleado)

Con la etiqueta <complexType>, le indicamos que el elemento es de tipo complejo (est
formado por otros) y con <sequence>, le decimos que est formado por una secuencia de
elementos.

Las etiquetas <annotation> y <documentation> se utilizan para definir comentarios
dentro del esquema.

El primer ejemplo sin utilizar ninguna referencia quedara:

<schema xmlns="http://www.w3.org/1999/XMLSchema"
xsi:schemaLocation="http://www.w3.org/1999/XMLSchema
http://www.w3.org/1999/XMLSchema.xsd"
targetNamespace="http://www.publishing.org/namespaces/CatalogoLibros"
elementFormDefault="qualified"
xmlns:cat="http://www.publishing.org/namespaces/CatalogoLibros">

<complexType>
<sequence>
<annotation>
<documentation>
Un catlogo de libros contiene cero o ms libros
</documentation>
</annotation>
<element name="Libro" minOccurs="0" maxOccurs="unbounded">
<complexType>
<sequence>
<element name="Titulo" type="string" minOccurs="1" maxOccurs="1"/>

24 de 137

<element name="Autor" type="string" minOccurs="1" maxOccurs="1"/>
<element name="Fecha" type="string" minOccurs="1" maxOccurs="1"/>
<element name="ISBN" type="string" minOccurs="1" maxOccurs="1"/>
<element name="Editorial" type="string" minOccurs="1" maxOccurs="1"/>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
</element>

</schema>

3.4. UTILIZACIN DE TIPOS DE DATOS PRIMITIVOS.

Para la utilizacin de los tipos predefinidos podemos usar el atributo type o a travs de la
etiqueta complexType para formar tipos complejos. Existe una restriccin sobre su uso, y es
que en la declaracin de un elemento se puede utilizar cualquiera de los dos, pero no ambos.

Creacin de un tipo complejo (ej. TarjetaCatalogo):

<complexType>
<sequence>
<element name="Libro" minOccurs="0" maxOccurs="unbounded" type="cat:TarjetaCatalogo"/>
</sequence>
</complexType>
</element>

<complexType name="TarjetaCatalogo">
<sequence>
</sequence>
</complexType>

TIPOS DE DATOS PRIMITIVOS (con ejemplos):

string: Hola Mundo
bolean: {true, 1, false, 0}
float: 12.56E3, 12, 12560, 0, -0, INF, -INF, NAN
double: 12.56E3, 12, 12560, 0, -0, INF, -INF, NAN
decimal: 7.08
timeDuration: P1Y2M3DT10H30M12.3S
recurringDuration: formato CCYY-MM-DDThh:mm:ss.sss
uriReference: http://www.xml.com
ID: [Slo debe ser usado con atributos]
IDREF: [Debe emparejar el valor de un atributo ID]

25 de 137

ENTITY
NOTATION
QNAME
language: Cualquier valor vlido de xml:lang (ej. EN, FR...)
IDREFS: Lista de valores IDREFS
ENTITIES
NMTOKEN: casa
NMTOKENS: yate casa
Name: parte (sin calificador de namespace)
NCName: cat:libro
integer: 456
nonPositiveInteger: desde - a 0
negativeInteger: desde - a -1
long: desde 9223372036854775808 a 9223372036854775808
int: desde 2147483648 a 2147483647
short: desde -32768 a 32767
byte: desde 127 a 128
nonNegativeInteger: desde 0 a
unsignedLong: desde 0 a 18446744073709551615
unsignedInt: desde 0 a 4294967295
unsignedShort: desde 0 a 65535
unsignedByte: desde 0 a 255
positiveInteger: desde 1 a
timeInstant: 1999-05-31T13:20:00-05:00
time: formato hh:mm:ss.sss
date: formato CCYY-MM-DD
month: formato CCYY-MM
year: formato CCYY
century: formato CC
recurringData: formato --MM-D
recurringDay: formato ---DD

3.5. DEFINICIN DE TIPOS DE DATOS DE USUARIO.

Con XSchema podemos crear nuestros propios tipos de datos basados en los tipos de
datos existentes. Los tipos base son los 40 tipos de datos descritos en el punto anterior. A estos
ya definidos se les pueden modificar aspectos facets para formar los nuestros. El esquema a
seguir es:

26 de 137

<simpleType name=nombre base=fuente>
<aspecto value=valor/>
<aspecto value=valor/>
...
</simpleType>

EJEMPLO TIPO1: ASPECTOS DEL TIPO STRING: El tipo String nos permite cambiar hasta
nueve aspectos:
pattern: patrones para el valor del elemento (mscaras).
enumeration: lista de valores.
length: longitud obligatoria.
maxlength: longitud mxima obligatoria.
minlength: longitud mnima obligatoria.
maxInclusive: valor mximo que puede incluir el elemento (alfabticamente).
maxExclusive: valor cuyo mximo es el anterior a ste.
minInclusive: valor mnimo que puede incluir el elemento.
minExclusive: valor cuyo mnimo es el posterior a ste.

Un ejemplo de tipo creado basndonos en el tipo string:

<simpleType name="TelefonoMovil" base="string">
<length value="10"/>
<pattern value="\d{3}-\d{6}"/>
</simpleType>
Este nuevo tipo TelefonoMovil almacena cadenas de
caracteres, pero su longitud tiene que ser
exactamente 10 y debe cumplir el patrn ddd-
dddddd. En este caso no hara falta el length, pues
con el pattern se lo indicamos (con \d{} le
indicamos los dgitos).

EJEMPLO TIPO2: ASPECTOS DEL TIPO INTEGER: El tipo integer permite cambiar los
siguientes aspectos:

pattern
enumeration
precision
scale
maxInclusive
maxExclusive

27 de 137

minInclusive
minExclusive

Ejemplo:
<simpleType name="Edad" base="integer">
<minInclusive value="0"/>
<maxInclusive value="200"/>
</simpleType>
Crea un nuevo tipo de dato Edad de tipo integer.
Sus valores estarn entre 0 y 200, ambos inclusive.

Si tenemos varios aspectos pattern y enumeration existir un OR entre ellos, es decir uno
u otro u otro... Mientras que el resto de aspectos se referirn a un AND.

<simpleType name="color" base="string">
<enumeration value="red"/>
<enumeration value="white"/>
<enumeration value="blue"/>
</simpleType>

EJEMPLO TIPO3: TIPO DATE: Los elementos declarados con tipo date deben cumplir el siguiente
formato: CCYY-MM-DD, donde el rango de CC es 00-99, al igual que el de YY; el rango de MM es
de 1-12; y el de DD depende del mes y del ao.

EJEMPLO TIPO4: TIPO YEAR: Los elementos declarados con este tipo deben tener la siguiente
estructura: CCYY donde CC e YY tienen un rango de 00-99.

[PARA MS INFORMACIN BUSCAR EN EL ANEXO 2]

3.6. EXPRESIONES REGULARES.

Los patrones o patterns especificados en los aspectos utilizan expresiones regulares.
Algunos ejemplos para entenderlas mejor:

Expresin
Regular
Ejemplo
Capitulo \d

Capitulo 1 (es un dgito de 0 a 9, por lo que Capitulo 10 no
valdra)

[] (Secuencia de caracteres)

28 de 137

-

(Si el est entre 2 valores es un rango, si va al principio o al
final es una secuencia)

a*b

b, ab, aab, aaab, ... (a aparece 0 ms veces)

[xyz]b

xb, yb, zb

a?b

b, ab (a puede venir o no, b est siempre)

a+b

ab, aab, aaab, aaaab, ... (a aparece 1 ms veces)

[a-c]x

ax, bx, cx

[-ac]x

-x, ax, cx

[ac-]x

ax, cx, -x

[^0-9]x

(cualquier caracter que no sea un dgito del 0 al 9 seguido de x)

\Dx

(cualquier caracter que no sea un dgito del 0 al 9 seguido de x)

\dx

(cualquier caracter que sea un dgito del 0 al 9 seguido de x)

Capitulo\s\d

(Capitulo seguido por un espacio en blanco y un dgito)

(ka){2} alli

kaka alli

(ka\s){2} alli

ka ka alli

.abc

(cualquier caracter seguido por abc)

(a|b)+c

ax, bx, aax, bbx, abx, bax, ...

a{1,3}x

ax, aax, aaax

a{2,}x

aax, aaax, aaaax, ...

29 de 137

\w\s\w

(obligatoriamente dos palabras entre un espacio en blanco)

Ejemplo con expresiones regulares: definicin del tipo de dato de una IP.

<simpleType name="IP" base="string">
<pattern value="(([1-9]?[0-9]1[0-9][0-9] | 2[0-4][0-9] | 25[0-5])\.{3} ([1-9]?[0-9]1[0-9][0-9] | 2[0-4][0-9] | 25[0-5])">
<annotation>
<documentation>
- Tipo de datos para representar direcciones IP. Ejemplos: 129.83.64.255, 64.128.2.71, etc.
- Este tipo de datos restringe cada campo de la direccin IP a tener un valor entre cero y 255:
[0-255].[0-255].[0-255].[0-255]
- En el atributo value le decimos que repita 3 veces acabando en punto (representado por "\.") y una cuarta sin l.
</documentation>
</annotation>
</pattern>
</simpleType>

3.7. DERIVACIN.

Los tipos derivados proceden de otros tipos de datos. Estos tipos pueden ser derivados
por extensin derivados por restriccin.

Cuando creamos un tipo de datos podemos prohibir algn tipo de derivacin:

<complexType name="Publicacion" final="#all" ...> No puede derivarse, ni por restriccin, ni por derivacin.
<complexType name="Publicacion" final="restriction" ...> No puede derivarse por restriccin
<complexType name="Publicacion" final="extension" ...> No puede derivarse por extensin.

3.7.1. Derivacin por extensin.

La derivacin por extensin consiste en coger un conjunto de datos, reutilizarlos todos,
adems de aadir los que se deseen.

<complexType name="Publicacion">
<sequence>
<element name="Titulo" type="string" minOccurs="1" maxOccurs="unbounded"/>
<element name="Autor" type="string" minOccurs="1" maxOccurs="unbounded"/>
<element name="Fecha" type="year" minOccurs="1" maxOccurs="1"/>
</sequence>
</complexType>

<complexType name="Libro" base="cat:Publicacion" derivedBy="extension">
<sequence>
</sequence>
</complexType>

30 de 137

3.7.2. Derivacin por restriccin.

Derivar por restriccin significa que no se pueden ni eliminar, ni aadir nuevos elementos
al conjunto de datos que se est reutilizando, solamente se pueden modificar, obligndonos a
definir todos los elementos de los que est compuesto, aunque no cambien.

Entonces, si derivar por restriccin es lo mismo que poner un nuevo tipo para qu sirve?,
pues, de esta forma me aseguro que todos los elementos que contiene son los mismos.

<complexType name="Publicacion">
<sequence>
</sequence>
</complexType>

<complexType name="PublicacionDeSolista" base="cat:Publicacion" derivedBy="restriction">
<sequence>
</sequence>
</complexType>

3.8. GLOBALES Y LOCALES.

Los elementos y tipos sern globales cuando sean hijos inmediatos del esquema, y sern
locales cuando estn anidados dentro de otros elementos o tipos.

3.9. EQUIVALENCIAS DE ELEMENTOS.

Dentro del mundo real hay muchos objetos o caractersticas que podemos nombrarlos de
diferente forma. Ejemplos: taxi vs pelas, ladrn vs caco, coche vs buga, etc.

Los XSchema pretenden resolver este conflicto de elementos equivalentes con
equivClass, e incluso puede sernos til por ejemplo si queremos amoldar el esquema a
mltiples idiomas.

Ejemplo:
<element name="pueblo" type="string"/>
<element name="village" equivClass="esp:pueblo" type="string"/>
<element name="herri" equivClass="esp:pueblo" type="string"/>

<element name="residencia">
<complexType>
<sequence>

31 de 137

<element ref="esp:pueblo"/>
</sequence>
</complexType>
</element>

Con el anterior, seran equivalentes las siguientes etiquetas en XML:
<residencia>
<pueblo>Berriz</pueblo>
</residencia>

<residencia>
<village>Berriz</village>
</residencia>

<residencia>
<herri>Berriz</herri>
</residencia>

Para que exista equivalencia, los elementos declarados como equivalentes debes ser
declarados como elementos globales y el tipo de los elementos debe ser el mismo que el del
elemento del que son equivalentes.

3.10. DECLARACIN DE ATRIBUTOS.

Para la declaracin de atributos se utilizan las etiquetas <attributeGroup> y
<attribute>. Siempre se declaran despus de la declaracin de elementos, slo pueden tener
simpleType y pertenecen al elemento dentro del cual estn anidados.

<complexType>
<sequence>
<element ref="cat:Libro" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>

<complexType>
<sequence>
<element ref="cat:Titulo" minOccurs="1" maxOccurs="1"/>
<element ref="cat:Autor" minOccurs="1" maxOccurs="unbounded"/>
<element ref="cat:Fecha" minOccurs="1" maxOccurs="1"/>
<element ref="cat:ISBN" minOccurs="1" maxOccurs="1"/>
<element ref="cat:Editorial" minOccurs="1" maxOccurs="1"/>
</sequence>
<attributeGroup ref:"cat:AtributosLibro"/>
</complexType>
</element>

<attributeGroup name="AtributosLibro">
<attribute name="categoria" use="required">
<simpleType base="string">
<enumeration value="autobiografia"/>
<enumeration value="no-ficcion"/>
<enumeration value="ficcion"/>
</simpleType>
</attribute>

32 de 137

<attribute name="EnStock" type="boolean" use="default" value="false"/>
<attribute name="Corrector" type="string" use="default" value=""/>
</attributeGroup>

<element name="Titulo" type="string"/>
<element name="Autor" type="string"/>
<element name="Fecha" type="string"/>
<element name="ISBN" type="string"/>
<element name="Editorial" type="string"/>

Cuando use es required entonces es que es obligatorio, y cuando es default, es que no lo
es.

3.11. GRUPOS DE ELEMENTOS.

Los elementos se pueden agrupar con la etiqueta <group>:

<complexType>
<sequence>
<group ref="cat:ElementosLibro"/>
</sequence>
<attribute name="categoria" use="required">
<simpleType base="string">
<enumeration value="autobiografia"/>
<enumeration value="no-ficcion"/>
<enumeration value="ficcion"/>
</simpleType>
</attribute>
<attribute name="EnStock" type="boolean" use="default" value="false"/>
<attribute name="Corrector" type="string" use="default" value=""/>
</complexType>
</element>

<group name="ElementosLibro">
<sequence>
<element name="Fecha" minOccurs="1" maxOccurs="1">
<complexType>
<sequence>
<element name="Mes" minOccurs="0" maxOccurs="1">
<simpleType base="positiveInteger">
<maxInclusive value="12"/>
</simpleType>
</element>
</sequence>
</complexType>
</element>
</sequence>
</group>

Las condiciones para agrupar elementos es que el grupo solo puede contener declaraciones
de elementos, nunca atributos; y el grupo debe ser global.

33 de 137

3.12. ELEMENTOS ALTERNATIVOS, REPETITIVOS, ALEATORIOS O VACOS.

3.12.1. Elementos alternativos.

Usamos la etiqueta <choice> para elegir un elemento entre una secuencia de ellos:

<element name="transporte">
<complexType>
<choice>
<element name="tren" type="string" minOccurs="1" maxOccurs="1"/>
<element name="avion" type="string" minOccurs="1" maxOccurs="1"/>
<element name="automovil" type="string" minOccurs="1" maxOccurs="1"/>
</choice>
</complexType>
</element>

Este esquema sera como <!ELEMENT transporte (tren|avion|automovil)> en DTD.

3.12.2. Repeticiones.

Para eso usamos la etiqueta <choice> con los atributos minOccurs y maxOccurs:

<element name="binario">
<complexType>
<choice minOccurs="0" maxOccurs="unbounded">
<element name="cero" type="unsignedByte" fixed="0" minOccurs="1" maxOccurs="1"/>
<element name="uno" type="unsignedByte" fixed="1" minOccurs="1" maxOccurs="1"/>
</choice>
</complexType>
</element>

Es como <!ELEMENT binario (cero|uno)*> en DTD.

3.12.3. Orden aleatorio.

Si queremos obtener una secuencia de elementos pero sin un orden fijo, utilizamos el tag
<all>. Los elementos declarados con esta etiqueta deben tener maxOccurs=1 y
minOccurs=1.

<complexType>
<sequence>
<element name="Libro" minOccurs="0" maxOccurs="unbounded">
<complexType>
<all>

34 de 137

</all>
</complexType>
</element>
</sequence>
</complexType>
</element>

3.12.4. Elementos vacos.

Se crean elementos vacos con el atributo content=empty dentro de complexType:

<element name="galeria">
<complexType>
<sequence>
<element name="imagen" minOccurs="1" maxOccurs="unbounded">
<complexType content="empty">
<attribute name="href" type="uriReference" use="required"/>
</complexType>
</element>
</sequence>
</complexType>
</element>

En una DTD, el ejemplo anterior sera: <!ELEMENT imagen EMPTY>
<!ATTLIST imagen href CDATA #REQUIRED>

3.12.5. Elemento ANY.

El elemento ANY permite que cualquier documento XML est bien formado, ya que es un
esquema comodn pues nos deja poner cualquier cosa.

<element name="libre">
<complexType>
<sequence>
<any minOccurs="0" maxOccurs="1"/>
</sequence>
</complexType>
</element>

3.12.6. Atributo ANY.

El atributo ANY permite utilizar cualquier atributo:

<element name="libre">
<complexType content="empty">
<anyAttribute/>
</complexType>

35 de 137

</element>

3.13. DEFINICIN DE CLAVES.

Una clave puede estar formada por un elemento o por la combinacin de varios. Por
definicin, una clave es nica sin necesidad de definirlo.

<key name="ClaveLibro">
<selector>Biblioteca/CatalogoLibros/Libro</selector>
<field>Titulo</field>
<field>@Categoria</field>
</key>

<selector> indica el camino que se necesita recorrer hasta llegar al elemento o elementos
que forman la clave. En este ejemplo, los campos tienen que ser hijos de Libro, que a su vez es
hijo de CatalogoLibros, y nieto de Biblioteca. Si quiero que la clave est formada por el atributo
de un hijo, ejemplo: <field>Titulo/@subtitulo</field>. (La @ va delante de atributos).

Tambin podemos definir unicidad, es decir, que sea nico sin tener que ser clave:

<unique name="LibroUnico">
<selector>Biblioteca/CatalogoLibros/Libro</selector>
<field>Titulo</field>
<field>@Categoria</field>
</unique>

36 de 137
4. CASCADING STYLE SHEETS (CSS).

4.1 INTRODUCCIN.

Para proporcionar un diseo a la pgina es conveniente utilizar el lenguaje de hojas de
estilo en cascada o CSS (del ingls cascading style sheet). Mediante este lenguaje podremos
modificar (sin tener que andar reescribiendo el cdigo continuamente):
el estilo de un elemento de la pgina (para ello utilizaremos el atributo id que identifica a
una etiqueta de otra en el documento).
el estilo de aquellos elementos de la pgina que pertenezcan a la misma clase
(utilizaremos el atributo class para asignar una clase a una etiqueta).
el estilo de todos los elementos de la pgina del mismo tipo (utilizaremos simplemente el
nombre de la etiqueta en cuestin.

Para referenciar una hoja de estilo desde el documento XML:

<? xml-stylesheet type=text/css href=nombre.css?>

CSS se utiliza para definir propiedades de formateo para elementos y atributos XML. Una
misma hoja de estilo se puede utilizar en mltiples documentos, que podrn ser preparados para
diferentes dispositivos de salida utilizando la hoja de estilo apropiada.

Existen 4 formas para aadir estilos:

interna: dentro del propio tag al que aplica el estilo.
embebida: mediante la etiqueta <STYLE>.
enlazada: a travs de <LINK>.
importada: dentro de <STYLE> pero con @import URL();

37 de 137

La secuencia de evaluacin es interna - embebida - enlazada - importada.

Ejemplos:

<H1 {font-size:12pt; font-weight:bold}>

INTERNA
<Style type="text/css">

</Style>

EMBEBIDA
<HEAD>
<LINK REL=stylesheet HREF=hoja.css TYPE=text/css>
</HEAD>

ENLAZADA
<STYLE type=text/css>
@import URL{hoja.css};
</STYLE>
IMPORTADA

4.2. SINTAXIS BSICA.

La sintaxis bsica es el selector (que puede ser una etiqueta, una clase [class] un
identificador [ID]) seguido de propiedades o lista de propiedades y el valor asignado:

selector {[propiedad:valor];...}

Por ejemplo, si queremos definir una justificacin total para los prrafos de la pgina
tendremos que escribir el siguiente cdigo:
P {text-align: justify}
</Style>

La asignacin de un valor a un determinado estilo se hace utilizando los dos puntos y no el
signo de igualdad. Es de destacar que en esta sintaxis no se diferencia entre maysculas y

38 de 137

minsculas. Si se hacen asignaciones de varias caractersticas del texto, stas se separan por
punto y coma.

Si se desea declarar el mismo estilo para varias etiquetas de tal forma que el estilo definido
con los valores para los diferentes atributos afecte a todas las etiquetas, se usar:

<STYLE>
etiqueta1, etiqueta2, ... etiquetaN {estilo:valor}
</STYLE>

Por ejemplo la siguiente regla asigna el color azul a todos los epgrafes del
documento:
H1, H2, H3, H4, H5, H6 {COLOR: BLUE}

Los valores se pueden agrupar pero el orden es decisivo, ya que font-weight y font-style se
deben especificar antes que el resto de propiedades.

En vez de:
P{font-family: Times, serif;
font-size: 12pt;
line-height: 20pt;
font-weight: normal;
font-style: italic}

Se puede usar:
P{font: normal italic 12pt/20pt Times, serif}

4.3. SELECTORES.

Como hemos dicho hay 3 clases de selectores:

Las etiquetas:
<style type=text/css>

</style>

39 de 137
Class: Dado que se puede necesitar el uso de diferentes versiones de estilos de un
mismo elemento, CSS permite la especificacin de clases. Para definir una clase se aade un
nombre de clase al nombre de la etiqueta en cuestin mediante la notacin punto.

Definicin Utilizacin

</style>
<body>
<b class=clsRojo>Texto</b>
<i class=clsRojo>Texto</i>
<h1 class=azul> Texto en azul</h1>
<h1 class=verde> Texto en verde</h1>
...
</body>

ID: Los identificadores funciona de una forma similar a las clases, pero estn limitados
a la utilizacin para un solo elemento. Se utiliza # en lugar del punto.

Definicin Utilizacin

</style>
<body>
<b id=idBoldItal>Texto</b>
<H2 id="titulo">Poemario</H2>
...
</body>

4.4. HERENCIA.

Tenemos que tener en cuenta que en el rbol de etiquetas de un documento se produce
herencia de los estilos, es decir se pueden especificar estilos globales en la etiqueta body, y as
en las etiquetas de los niveles inferiores slo ser necesario sobrescribir los estilos que se
heredan.

40 de 137

4.5. PROPIEDADES

PRRAFOS
Mediante las hojas de estilos podemos modificar el margen, el borde, fondo, sangra e
interlineado de los prrafos. Las propiedades que nos permiten modificar tales caractersticas
son:
margin-top
margin-right
margin-bottom
margin-left
Definen respectivamente el margen superior, derecho, inferior e izquierdo del
prrafo en pixels o en porcentaje de pantalla.
margin Define el margen superior, derecho, inferior e izquierdo del prrafo. Si slo se
escribe un valor el margen se aplica por igual a los cuatro mrgenes. Si se
escriben dos, el primer valor se aplica a los mrgenes superior e inferior, y el
segundo a los mrgenes izquierdo y derecho. Por ltimo si se escriben tres
valores, el primero se aplica al margen superior, el segundo al margen
izquierdo y derecho, y el tercero al margen inferior.
padding-top
padding-right
padding-
bottom
padding-left
En el caso de que el prrafo tenga un borde, definen el espacio que hay entre
el contenido del prrafo y los bordes superior, derecho, inferior e izquierdo del
prrafo en pixels o porcentaje.
padding Define el espacio que hay entre el contenido del prrafo y los bordes superior,
derecho, inferior e izquierdo del prrafo en pixels o porcentaje. La aplicacin de
slo un valor, dos o tres valores, sigue las mismas reglas que las de la
propiedad margin.
border-top
border-right
border-bottom
border-left
Definen respectivamente el estilo, color y ancho del borde superior, derecho,
inferior e izquierdo del prrafo. Los valores posibles para el estilo son none,
solid y double. El color se dar en notacin hexadecimal o mediante su nombre
en ingls. Y el grosor se proporcionar en pixels.
border Define el estilo, color y ancho del borde superior, derecho, inferior e izquierdo
del prrafo. La aplicacin de slo un valor, dos o tres valores, sigue las mismas
reglas que las de las propiedades margin y padding.
background-
color
Define el color de fondo del prrafo.
background-
image
Define la imagen de fondo del prrafo. El valor se debe proporcionar con el
siguiente formato: url(imagen).

41 de 137

background-
attachment
Define si el fondo permanecer fijo (fixed), o no (scroll), respecto del texto. No
funciona con los prrafos.
background-
repeat
Define si la imagen se repite, repeat; se repite solamente horizontalmente,
repeat-x; verticalmente, repeat-y; o simplemente no se repite, no-repeat.
background-
position
Define la posicin superior e izquierda de la imagen en pixels o porcentajes.
background Define el color, la imagen, repeticin, fijacin o no del fondo y posicin de la
imagen. NOTA: Es mejor utilizar la combinacin de nmero hexadecimales que
los nombre de colores ya predefinidos porque pueden ser diferentes en
navegadores distintos ({background:red, es mejor {background:#6633FF}
text-indent Define la sangra de primera lnea del prrafo en pixels.
text-transform Define los efectos sobre el prrafo (conversin a maysculas, etc..). Los
valores posibles: capitalize, uppercase, lowercase y none.
text-align Define la alineacin del prrafo. Los valores posibles son: left, center, right y
justify.

Veamos un ejemplo:

P {margin-left: 20; margin-right: 20; padding: 5; border: solid white 2;
background-color: #C0C0C0; text-indent: 20; text-align: justify}
Este prrafo tiene un margen izquierdo y derecho de 20 pixels, un espaciado entre el
texto y el borde de 5 pixels, un borde slido de color blanco de 2 pixels de anchura, un
fondo de color gris,una sangra de primera lnea de 20 pixels y alineacin justificada.

CARACTERES
Veamos ahora cuales son las propiedades que nos permiten modificar el estilo de los
caracteres:
font-style Permite mostrar el texto en cursiva mediante el valor italic . Su valor por
defecto es normal.
font-variant Permite mostrar el texto en formato de VERSALES mediante el valor small-caps.
Su valor por defecto es normal.
font-weight Permite mostrar el texto en negrita mediante el valor bold . Su valor por
defecto es normal.
font-size Define el tamao del tipo de letra en pixels o porcentaje (teniendo en cuenta el
tamao de la fuente actual).

42 de 137

line-height Define el espacio de interlineado del prrafo en picas. He incluido el
interlineado en esta seccin debido a que forma parte de uno de los valores de
la propiedad font expuesta ms abajo. Pero en realidad se trata de una
propiedad para prrafos.
font-family Define el tipo de letra. Si el nombre de la fuente contiene espacios es
conveniente entrecomillarlo. Si se trata de un estilo insertado utiliza las
comillas simples para no confundirlas con las dobles.
font Define los formatos de cursiva, versales y negrita; el tamao de la fuente, el
interlineado del prrafo; y finalmente el tipo de letra.
color Define el color de la fuente.
vertical-align Define los formatos de
subndice
y
superndice
del texto.
letter-spacing D e f i n e e l e s p a c i a d o e n t r e c a r a c t e r e s e n p i x e l s .

El siguiente cdigo muestra un prrafo de ejemplo en el que hemos modificado el estilo de
algunas de sus palabras:

<P style="margin-left: 20; margin-right: 20; line-height: 2; font-family:'Comic Sans MS'; background-
color: #FFFFE0 ;">
"No habra ido yo a matar a un padre ni a llamarme el mundo novio de aquello de lo que nac. Pero as
soy un <Span style="font-size:110%; color: blue">sin-dios</Span>, hijo de crimen soy, cra comn
mi cra con la de quien sal; y si algo ms hondo an hay en el mal del mal, en ello es parte <Span
style="letter-spacing:4"> Edipo</Span>"
</P>

"No habra ido yo a matar a un padre ni a llamarme el mundo novio de aquello de lo que nac. Pero as
soy un sin-dios, hijo de crimen soy, cra comn mi cra con la de quien sal; y si algo ms hondo an
hay en el mal del mal, en ello es parte E d i p o "

Nota 1: Observa que he utilizado las propiedades line-height y font-family dentro de la
etiqueta <P>. En principio, y salvo algunas excepciones ms o menos evidentes, las propiedades
de las hojas de estilo se pueden aplicar a todas las etiquetas de HTML. He empezado por agrupar
los estilos que se pueden aplicar a las etiquetas de prrafo, etiquetas que delimitan su contenido
y lo tratan como un bloque ()como son las etiquetas <Hn>, <P>, <Pre>, <Strong> y <Div>); y

43 de 137
he continuado con estilos que se pueden aplicar fundamentalmente a etiquetas que no definen
bloques (como son <Strong>, <Em> o <Span>).

LISTAS
Gracias a los estilos podemos definir el tipo, imagen y posicin de las listas:
list-style-type Define el tipo de lista. Los valores disponibles son: disc, circle, square, decimal,
lower-roman, upper-roman, lower-alpha, upper-alpha y none.
list-style-
image
Define una imagen para los elementos de la lista. El valor se debe proporcionar
con el siguiente formato: url(imagen).
list-style-
position
Define si la lista tiene sangra francesa, outside, o no, inside.
list-style Define el tipo, la imagen de los elementos y la sangra de la lista.

El siguiente cdigo inserta una lista con imgenes:
<Ul style="list-style-image: url(l1.jpg); font-weight:bold; background-color: #FFFFE0 ">
<Li>HTML</Li>
<Li>CSS</Li>
<Li>JavaScript</Li>
</Ul>

HTML

CSS

JavaScript

IMGENES
Podemos modificar el margen y el borde de las imgenes mediante las propiedades que
vimos anteriormente en la seccin de prrafos. Tambin pueden resultar de utilidad las
siguientes propiedades:
float Recuerda el ejemplo de alineacin de imgenes que vimos en el captulo II.
Cuando asignbamos el valor left o right al atributo align de la etiqueta <Img>,
el texto se situaba a su izquierda o derecha. Decamos que la imagen flotaba a

44 de 137

izquierda o derecha del texto. Pues bien, asignar el valor left o right a la
propiedad float consigue el mismo efecto.

vertical-align Los valores top, middle y bottom de esta propiedad son equivalentes a los
mismos valores del atributo align de las imgenes.

VNCULOS
Ya hemos visto como definir estilos para las diferentes pseudoclases de los vnculos. Dos
propiedades que te pueden ayudar a modificar an ms tales elementos son:
text-decoration Define los formatos de estilo subrayado, underline; sobre-rayado, overline;
tachadura, line-through; y ninguno, none.
cursor Define diferentes tipos de puntero para el ratn entre los que se encuentran:
crosshair, default, hand, move, text, wait y help.

Mediante el valor none de la propiedad text-decoration puedes evitar el subrayado de los
vnculos:
A:link, A:visited, A:active {text-decoration: none}

FORMULARIOS Y TABLAS
Los elementos Form y Table admiten casi todas las propiedades de estilo vistas hasta el
momento: las propiedades de prrafo, las propiedades de caracteres, etc. Ahora bien, puesto
que ambos elementos contienen a su vez subelementos (como las celdas de las tablas y los
botones de los formularios), el comportamiento de algunas de estas propiedades diferir segn
se apliquen a la tabla o formulario, o a alguno de sus subelementos.
Por ejemplo, mientras que la propiedad text-align alinear la tabla a izquierda, centro o
derecha, la misma propiedad referida a sus subelementos Td seleccionar una alineacin para el
contenido de sus celdas. Luego las dos siguientes reglas sirven a propsitos diferentes:
TABLE {text-align: center}
TD {text-align: center}
Celda 1 Celda 2

45 de 137
Tampoco ser lo mismo asignar un fondo al formulario que a alguno de sus subelementos
Input. En especial puedes obtener efectos impactantes con los cuadros de texto de una sola lnea
y con los botones:
INPUT {background-color: #4682B4; color: white; font-weight: bold}

CSS-P (POSICIONAMIENTO)
Por ltimo vamos a ver una serie de propiedades que tienen que ver con la posicin de los
elementos en la pgina. Estas propiedades se utilizan generalmente para crear animaciones
mediante scripts. Las que puedes utilizar:
position Define la posicin de un elemento el el documento como absolute, relative o
static.
left, top, width y
height
Definen la posicin del elemento mediante la especificacin de su esquina
superior izquierda, su anchura y su altura.
z-index Define la posicin del elemento con respecto al resto de elementos de la
pgina.

La posicin por defecto de un elemento HTML es static. Si queremos variar la posicin de
un elemento tendremos que asignar a la propiedad position del elemento el valor absolute o
relative. Las dos imgenes siguientes tienen posiciones absolutas y relativas respectivamente:

Fjate que mientras la posicin relativa no parece diferir en nada de la posicin normal,
static, la posicin absoluta sita la imagen de una manera anmala. Esto se debe a que cada tipo
de ubicacin utiliza un sistema de coordenadas diferente. Los elementos con posicin absoluta
utilizan la esquina superior del documento para su ubicacin con independencia del flujo del resto
de elementos del texto:

<P>La siguiente imagen <Img style="position: absolute; left: 20; z-index: -1"
src="pepper.gif" alt="absoluta" width="55" height="69">est situada...

46 de 137
La siguiente imagen est situada a 20 pixels del lado izquierdo del documento. Observa que
ste prrafo se muestra en el navegador como si no hubiera ninguna imagen insertada en l. El
valor - 1 de la propiedad sita a la imagen detrs del texto (de todas formas he suavizado la
imagen para que no emborrone el texto).
Por su parte los elementos con posicin relativa tienen como origen de coordenadas la
posicin dentro de la que se encuentran. Observa que la diferencia con el cdigo anterior es, tan
solamente, el valor de la posicin:

<P>La siguiente imagen <Img style="position: relative; left: 20; z-index: -1"
src="pepper.gif" alt="absoluta" width="55" height="69">est situada...
La siguiente imagen est situada a 20 pixels del lado izquierdo de su origen de
coordenadas. Observa como difiere su posicin de la anterior a pesar de tener ambas el mismo
valor para su propiedad left.

4.6. DIV Y SPAN.

Las etiquetas <Div> y <Span> permiten definir mbitos definidos por el usuario. Ya
conoces lo que es el mbito de una etiqueta, pero quizs quieras agrupar un grupo de etiquetas,
de manera que puedas aplicarles un estilo de forma compacta. En el ejemplo siguiente vamos a
utilizar un elemento Div para definir un margen izquierdo de 50 pixels para un prrafo y una
imagen contenidos en l. La etiqueta <Div> es similar a las etiquetas de prrafo. Su contenido
es tratado como un bloque, por lo cual inserta un punto y aparte automtico despus de su
etiqueta de cierre:
<Div style="margin-left:50" class="ej">
<P>Este es un prrafo hijo de un elemento Div que define un margen
izquierdo de 50 pixels. La imagen siguiente tambin pertenece al mbito del
elemento DIV. Y por ello comparte el mismo margen izquierdo que el
prrafo.</P>

<P><Img src="bolsa3.jpg" width="56" height="80" alt="bolsa con margen
de 15 pixels"></P>
</Div>

47 de 137
Este es un prrafo hijo de un elemento Div que define un margen izquierdo de 50 pixels. La
imagen siguiente tambin pertenece al mbito del elemento DIV. Y por ello comparte el
mismo margen izquierdo que el prrafo.

Por su parte la etiqueta <Span> nos permite definir mbitos insertados dentro de un
bloque. El siguiente cdigo muestra la frase en color rojo:

<P style="text-align:center">No ir a conocer la misma suerte,
<Span style="color: red">a acostarme para no levantarme jams?</Span>
</P>

No ir a conocer la misma suerte, a acostarme para no levantarme jams?

4.7. CASOS ESPECIALES: PSEUDOELEMENTOS Y PSEUDOCLASES.

El concepto de pseudoelementos o pseudoclases permite el formateo de elementos
basndose en informacin que no est contenida en el rbol del documento.

Los pseudoelementos permiten acceder a informacin que de otra forma no est accesible,
permiten definir instrucciones para elementos que no estn contenidos en el cdigo fuente:

PSEUDOELEMENTOS EJEMPLOS
first-line (primera lnea) p:first-line {text-transform: uppercase}
first-letter (primer letra) p:first-letter {font-size: 200%; font-style: italic}
before, after (insercin dinmica de
contenido antes o despus de un elemento)
h1:before {content: counter (chapno, upper-roman)
.}

Las pseudoclases permiten clasificaciones lgicas de los elementos; normalmente, las
caractersticas no se pueden extraer del rbol del documento.

48 de 137

Debido a que los vnculos pueden presentar diferentes estados (sin visitar, visitado y activo)
el selector para la etiqueta <A> presenta una serie de pseudoclases (clases pertenecientes
solamente a esta etiqueta) que te pueden ayudar a definir los estilos de tales estados. El
siguiente cdigo define el color negro para los vnculos por defecto, el color blanco para los
vnculos visitados y el color rojo para los vnculos activos (fjate en los dos puntos que separan el
selector de su pseudoclase!):
A:link {color: black}
A:visited {color: white}
A:active {color: red}
</Style>

Otras pseudoclases:

PSEUDOCLASES
first-child (el primer hijo) p:first-child {text-transform: uppercase}
active, hover, focus Cambia la representacin debido a la interaccin del
usuario. (las pseudoclases link y visited) solo se pueden
aplicar a la etiqueta A en HTML).
lang Hace que los elementos dependan del idioma.

4.8. USO DE DIFERENTES MEDIOS.

Existe el atributo media a travs de @import o LINK para especificar el medio de salida, de
esta forma dependiendo del medio en el que se va a mostrar, elige la CSS determinada para
dicho medio.

IMPORT LINK
@import url (loudvoice.css aural;
@media print{...}
<HEAD>
<TITLE>seleccin de otro medio</TITLE>
<LINK rel=stylesheet type=text/css media=print, handled href=print.css>
</HEAD>
...

Se ponen diferentes atributos media para cada medio que se quiere hacer, y es el propio
navegador el que detecta el medio. Los tipos de medios soportados (REC-CSS2:1998):

all aplicable a todos los tipos
aural para sintetizadores de voz
braille para dispositivos braille

49 de 137

embossed para impresoras de pginas braille
handheld dispositivos handheld (pantallas pequeas, monocromo, anchura de banda
limitada)
print para documentos visualizados en print mode (Ej. PDF...)
projection para documentos visualizados en formato proyeccin (Ej. PowerPoint
Viewer)
screen para pantallas en color
tv para dispositivos de tipo televisin (baja resolucin, color, sonido)

Obviamente, existen propiedades de las CSS habituales que conocemos que no tienen
ningn sentido en algunos medios, al igual que existirn otras propiedades exclusivas para
diversos medios.

Ms informacin en http://www.w3.org/TR/REC-CSS2

4.9. EJEMPLO XML CON CSS.

Si tenemos este XML con hojas de estilos:

<?xml-stylesheet type="text/css" href="hamlet.css"?>
<Play>
<Annotation> Use XML, HATEML, sorry HAMLET and Style Sheets </Annotation>
<Title> Hamlet </Title>
<STitle> Prince of Denmark </STitle>
<Act>
<Title>Act 1</Title>
<Scene>
<Title>Scene 1</Title>
<Action>
<Speaker>MARCELLUS</Speaker>
<Mar>
<Line>'Tis gone!</Line>
</Mar>
<Directive>[Exit Ghost]</Directive>
<Speaker>MARCELLUS</Speaker>
<Mar>
<Line>We do it wrong, being so majestical,</Line>
<Line>To offer it the show of violence;</Line>
<Line>For it is, as the air, invulnerable,</Line>
<Line>And our vain blows malicious mockery.</Line>
</Mar>
<Speaker>BERNARDO</Speaker>
<Ber>
<Line>It was about to speak, when the cock crew.</Line>
</Ber>
<Speaker>HORATIO</Speaker>
<Hor>
<Line>And then it started like a guilty thing</Line>
<Line>Upon a fearful summons.</Line>
</Hor>
</Action>
</Scene>
</Act>

50 de 137
</Play>

Y esta hoja de estilos CSS:

Play {font-family: Arial, sans-serif; color: black; background: #F3EDE0; Display:block;}
Annotation {Display: none;}
Play Title {Display: Block; background:#E6E5E5; font-family: verdana, Arial, sans-serif; font-size: 30pt;
font-weight: bold; color: #006699; text-align: center}
Play STitle {Display: Block; background:#F0F0F0; font-size: 15pt; font-weight: bold; color: #666666;
text-align: center}
Act Title {font-size: 12pt; color: blue; text-align: left}
Scene Title {background:#DFE8EC; display:inline; font-size: 10pt; color: #000066; text-align: left }
Directive {font-family: Arial, sans-serif; Display: Block; font-size: 10pt; font-Style: italic; color: blue;}
Speaker {Display: Block; font-family: Lucida Console; font-size: 12pt; margin-top: 10px; font-weight:bold;}
Action {font-family: arial; font-size: 12pt;}
Action Mar {font-family:Verdana; color: #7D2515;}
Action Ber {font-family:Verdana; color: #9933aa;}
Action Hor {font-family:Verdana; color: #666699;}
Line {Display: Block;}

La pgina XML se visualiza:

51 de 137
5. MODELO DE PROCESO DE XSLT.

5.1. INTRODUCCIN.

(MS INFORMACIN EN CAPTULO 14 DE LA BIBLIA DE XML: TRANSFORMACIONES XSL
http://www.ibiblio.org/xml/books/bible/updates/14.html)

El XSL (eXtensible Stylesheet Language) es un lenguaje que nos permite definir una
presentacin o formato para un documento XML. Un mismo documento XML puede tener varias
hojas de estilo XSL que lo muestren en diferentes formatos (HTML, PDF, RTF, VRML, PostScript,
sonido, etc.). En definitiva, el XSL se puede definir como un lenguaje de hojas de estilo que nos
permite dar al XML un formato de salida (el XSL no es ms que un documento XML, por lo que
debe tambin ser vlido).

El XML describe los contenidos, el XSL la presentacin mientras que el HTML mezcla
contenidos con presentacin. Para describir cmo se deben presentar los documentos XML
podemos optar por dos soluciones: las CSS que se utilizan con HTML y/o las descripciones que se
basan en XSL. CSS es eficaz para describir formatos y presentaciones, pero no sirve para decidir
qu tipos de datos deben ser mostrados y cules no deben salir en la pantalla. Esto es, CSS se
utiliza con documentos XML en los casos en los que todo su contenido debe mostrarse sin mayor
problema. XSL no solo permite especificar cmo queremos presentar los datos de un documento
XML, sino que tambin sirve para filtrar los datos de acuerdo a ciertas condiciones. Se parece un
poco ms a un lenguaje de programacin. El XSL aade al XML, adems del aspecto que ya
inclua CSS referente a la presentacin y estilo de los elementos del documento, una pequea
sintaxis de lenguaje script para poder procesar los documentos XML de forma ms cmoda.
Adems, XSL no es incompatible con las CSS, es decir que podemos utilizar ambos formatos
para la presentacin de los documentos.

52 de 137

Lo que se pretende con la hoja de estilo es realizar una transformacin desde un
documento XML a un rbol resultante. Para ello necesitamos saber la jerarqua del XML.

Los formatos de salida (rbol resultante) de este proceso de transformacin son HTML, XML
texto. Tambin existen otros formatos como PDF, pero este utiliza XSLT para seleccionar y FO-
XSL para formatear el documento.

Mientras que al documento HTML slo se le poda aplicar una CSS para presentarlo, al XML
le puedo aplicar, un lenguaje de formateo (XSL-FO), una CSS o un lenguaje de transformacin
(XSLT), hasta llegar a la presentacin. Las CSS las interpreta el navegador, pero el XSLT o el
XSL-FO necesitan un procesador para poder verse los resultados.

El documento XML tiene una estructura de rbol, donde cada etiqueta corresponde a un
nodo del rbol. Como todos sabemos, el documento XML tiene que estar bien formado por lo que
debe existir una etiqueta raz que contiene al resto de elementos; sin embargo, sta no es la raz
del rbol XML, existe otra que las contiene (/).

Ejemplo:

CDIGO XML
<catalogo>
<crucero estado="disponible">
<precio>870</precio>
<descripcion>Crucero en el atlntico.</descripcion>
<yate>CARMEN</yate>
<puertosalida>AZORES</puertosalida>
<puertollegada>GRAN CANARIA</puertollegada>
</crucero>
<crucero estado="no disponible">
<descripcion>Crucero por el caribe.</descripcion>
<yate>AQUIVA</yate>
<puertosalida>SANTA LUCIA</puertosalida>
<puertollegada>SANTA LUCIA</puertollegada>
</crucero>
</catalogo>

53 de 137
RBOL DEL DOCUMENTO XML

A travs de la estructura de rbol del documento XML podemos ir recorriendolo accediendo
a los elementos y atributos.

5.2. TEMPLATES.

A travs de templates o plantillas puedo obtener el documento resultante a partir del
fuente, para ello selecciona la informacin con patrones de bsqueda (filtro) y aplicando
reglas de proceso.

Las reglas template tienen la siguiente estructura general:

EJEMPLO
<xsl:template match=patrn>
accin
</xsl:template>
<xsl:template match=crucero>
El precio es:
<xsl:value-of select=precio/>
<xsl:apply-templates/>
</xsl:template>

Donde patrn es el identificador de los elementos a los que queremos aplicar la template.
Es decir, en el recorrido por el rbol del documento cuando encuentre un nodo que coincida con
el patrn del template aplica la plantilla.

As un documento XSL tendr el siguiente esquema:

<?xml version=1.0?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match=/>
[accion1]
</xsl:template>

54 de 137

<xsl:template match=patron1>
[accion2]
</xsl:template>
[accion3]
</xsl:template>
[accion4]
</xsl:template>
..........
</xsl:stylesheet>

Como vemos la hoja de estilo est definida entre las etiquetas <xsl:stylesheet> y
</xsl:stylesheet>, y debemos indicarle el namespace que se utiliza a travs del atributo
xmlns:xsl. Por tanto, lo primero que necesita un fichero XSL es identificar el namespace XML
que nos permite validar todos los elementos y mtodos disponibles en la versin XSL que se
utiliza. De esta forma, el namespace reconoce los atributos y elementos XSL del documento que
le da el formato de salida al XML.

En el esquema anterior hemos utilizado el namespace que utiliza la recomendacin del W3C
del 16 de noviembre de 1999. El namespace de la recomendacin del W3C de diciembre de 1998
es http://www.w3.org/XSL/Transform/1.0.

Si tuvisemos estos patrones:

<?xml version=1.0?>
[accion1]
</xsl:template>
<xsl:template match=catalogo>
[accion2]
</xsl:template>
[accion3]
</xsl:template>
<xsl:template match=yate>
[accion4]
</xsl:template>
</xsl:stylesheet>

Cuando el procesador identifique al elemento raz hace accion1, cuando identifique el
elemento catalogo hace accion2, y as hasta que termina de recorrer el rbol...

55 de 137

A los templates les puedo dar un nombre y despus llamarlo con <xsl:call-template
name=[nombre]>:

<xsl:template name=nombre>
accin
</xsl:template>

Aunque para esto, hay que tener en cuenta que al llamarlo busca el nombre de los nodos
que estn por debajo desde donde se llama (o poner name=//nombre para que lo busque
por todo el rbol).

5.3. CREACIN DE UNA HOJA DE ESTILO.

Antes que nada debemos conocer la estructura del rbol, y despus construir la cabecera y
el cuerpo HTML incrustndolos en alguna template (normalmente es en el raz):

<HTML>
<HEAD>
<TITLE>El ttulo</TITLE>
</HEAD>
<BODY>
</BODY>
</HTML>
</xsl:template>

Con este ejemplo, genera cdigo HTML, incrustando dentro de <body> el resultado de la
sentencia <xsl:apply-templates/>. sta procesa todos los nodos de forma recursiva, y si
encuentra alguna otra plantilla dentro del documento XSL con <xsl:template match=...
emparejada al nodo que se est procesando, le aplica dicha plantilla.

Por ltimo, para la creacin de una hoja de estilo escribiremos una regla template por cada
nodo aadiendo las instrucciones de proceso necesarias, sabiendo qu sentencias XSL provocan
desplazamiento por el rbol (xsl:template, xsl:for...) y cules no (xsl:if, xsl:value-of...).

EJEMPLO
</xsl:template>

56 de 137

<xsl:template match=catalogo>

El precio es:
<B><xsl:value-of select=precio/></B>
<BR/>
</xsl:template>

.......

En el tercer template voy recorriendo todos los nodos crucero, y en cada uno de ellos con la
sentencia <xsl:value-of... voy mostrando el valor del nodo precio, ste lo busca por debajo de
crucero, si no existe el elemento precio no muestra nada (si queremos que muestre el contenido
de crucero, es decir del nodo en el que nos encontramos tendremos que escribir <xsl:value-of
select=./>). La peculiaridad de este tercer template es la incrustacin de cdigo HTML, ya
que se le aade las instrucciones necesarias para obtener los resultados como deseemos. As,
obtendremos el valor de precio en negrita seguida de un <BR>, que si nos fijamos al tener que
ser un documento bien formado debe estar cerrado.

Si estamos situado en un nodo cualquiera, para acceder a los nodos hijos en el rbol se
ponen los nombres de stos, si queremos conseguir el contenido del propio nodo en el que nos
encontramos lo referenciamos con ., y si queremos retroceder, con ... Para acceder a
cualquier otro nodo del rbol, podemos ir movindonos por el rbol con sentencias XSL o ir
directamente a travs de rutas (Ej. //descripcion lo busca desde el raz independientemente
donde estemos situado, crucero/descripcion accede a descripcion pero debemos estar situado
en catalogo que es anterior a crucero...).

EJEMPLO XML/XSL/HTML

Si tenemos el siguiente documento XML:
<?xml-stylesheet type="text/xsl" href="equipos.xsl"?>
<liga>
<equipo id="1">
<nombre ciudad="MADRID">REAL MADRID CF</nombre>
<escudo file="imagenes\real_madrid.gif"/>
<estadio>SANTIAGO BERNABU</estadio>
</equipo>
<equipo id="2">
<nombre ciudad="BARCELONA">FC BARCELONA</nombre>
<escudo file="imagenes\barcelona.gif"/>
<estadio>NOU CAMP</estadio>
</equipo>
<equipo id="3">
<nombre ciudad="BILBO">ATHLETIC CLUB</nombre>
<escudo file="imagenes\athletic.gif"/>

57 de 137

<estadio>SAN MAMS</estadio>
</equipo>
<equipo id="4">
<nombre ciudad="VALENCIA">VALENCIA CF</nombre>
<escudo file="imagenes\valencia.gif"/>
<estadio>MESTALLA</estadio>
</equipo>
<equipo id="5">
<nombre ciudad="ALMENDRALEJO">CF EXTREMADURA</nombre>
<escudo file="imagenes\extremadura.gif"/>
<estadio>FRANCISCO DE LA HERA</estadio>
</equipo>
</liga>

Con la hoja de estilo:


<xsl:template match="/">
<html>
<head>
<title>EQUIPOS</title>
</head>
<body bgcolor="navy">
<xsl:apply-templates select="liga"/>
</body>
</html>
</xsl:template>


<xsl:template match="liga">
<table border="0" align="center" bgcolor="white" style="font-size:10pt; font-family:verdana;">
<tr>
<td align="center" colspan="2" bgcolor="#DFE8EC"><b>EQUIPO</b></td>
<td align="center" bgcolor="#DFE8EC"><b>ESTADIO</b></td>
</tr>
<xsl:apply-templates select="equipo"/>
</table>
</xsl:template>


<xsl:template match="equipo">
<tr>
<td><img height="70" width="60">
<xsl:attribute name="src"><xsl:value-of select="escudo/@file"/></xsl:attribute>
</img>
</td>
<td bgcolor="#DFE8EC"><xsl:value-of select="nombre"/>
(<b><xsl:value-of select="nombre/@ciudad"/></b>)
</td>
<td bgcolor="#DFE8EC" align="center"><xsl:value-of select="estadio"/></td>
</tr>
</xsl:template>

</xsl:stylesheet>

Obtendremos el documento de salida HTML:
<html>
<head>
<title>EQUIPOS</title>
</head>

58 de 137
<body bgcolor="navy">
<table border="0" align="center" bgcolor="white" style="font-size:10pt; font-family:verdana;">
<tr>
<td align="center" colspan="2" bgcolor="#DFE8EC"><b>EQUIPO</b></td>
<td align="center" bgcolor="#DFE8EC"><b>ESTADIO</b></td>
</tr>
<tr>
<td><img height="70" width="60" src="imagenes\real_madrid.gif"></td>
<td bgcolor="#DFE8EC">REAL MADRID CF (<b>MADRID</b>)</td>
<td bgcolor="#DFE8EC" align="center">SANTIAGO BERNABÉU</td>
</tr>
<tr>
<td><img height="70" width="60" src="imagenes\barcelona.gif"></td>
<td bgcolor="#DFE8EC">FC BARCELONA (<b>BARCELONA</b>)</td>
<td bgcolor="#DFE8EC" align="center">NOU CAMP</td>
</tr>
<tr>
<td><img height="70" width="60" src="imagenes\athletic.gif"></td>
<td bgcolor="#DFE8EC">ATHLETIC CLUB (<b>BILBO</b>)</td>
<td bgcolor="#DFE8EC" align="center">SAN MAMÉS</td>
</tr>
<tr>
<td><img height="70" width="60" src="imagenes\valencia.gif"></td>
<td bgcolor="#DFE8EC">VALENCIA CF (<b>VALENCIA</b>)</td>
<td bgcolor="#DFE8EC" align="center">MESTALLA</td>
</tr>
<tr>
<td><img height="70" width="60" src="imagenes\extremadura.gif"></td>
<td bgcolor="#DFE8EC">CF EXTREMADURA (<b>ALMENDRALEJO</b>)</td>
<td bgcolor="#DFE8EC" align="center">FRANCISCO DE LA HERA</td>
</tr>
</table>
</body>
</html>

Se visualizar:

59 de 137

5.4. XPATH.

Siempre que nos movemos por el documento utilizamos XPATH, ya que es un indicador de
caminos y podemos usar estas expresiones en muchas sentencias del documento:

<xsl:template match=/catalogo/crucero/>
Con esta sentencia nos situamos en crucero (dentro de
catalogo y dentro de /)

<xsl:value-of select=precio/>
Al no ponerle nada delante del nombre del elemento le
indicamos que busque por debajo del elemento actual.

<xsl:apply-templates select=ruta/puerto/>
Le decimos que plantillas tiene que aplicar (puerto que
est dentro de ruta hijo del elemento actual)
</xsl:template>

La identificacin del camino pueden ser absoluta o relativa, es decir en base al raz o en
base al nodo actual (Es una direccin absoluta si empieza por /, y relativa cuando no sea as).

Identificar el
documento


Cuando comienzes el documento...

Identificacin por
nombre


<xsl:template match=//crucero>

Cuando encuentres un elemento
crucero.... La 1 de forma relativa
(dependiendo de la posicin actual) y la 2
de forma absoluta (//crucero es igual que
/*/crucero.

Identificacin de
varios elementos

<xsl:template match=yate | marinero>

Cuando encuentres un elemento yate o un
elemento crucero.... | es un OR pero en
realidad es un AND, porque si encuentra el
1 lo hace, y cuando encuentra el 2
tambin.

Identificacin con
un ancestro
inmediato

<xsl:template match=crucero/precio>

Cuando encuentres un elemento precio
que tiene un elemento crucero como
padre...

Identificacin con
un ancestro

<xsl:template match=catalogo//puerto>

Cuando encuentres un elemento puerto
que tiene un elemento catalogo como
antecesor.... (Da igual donde est, puede
estar inmediatamente debajo o en algn
nodo descendiente cualquiera).

Identificacin con
comodn
<xsl:template match=crucero/*>

Cuando encuentres cualquier elemento
hijo inmediato del elemento crucero....

60 de 137

(Siendo crucero hijo del nodo actual).

Dentro de la jerarqua de un rbol tenemos que saber bien varios conceptos: siblings o
nodos hermanos (mismo nivel que un nodo cualquiera), children o hijos inmediatos, descendants
o descendientes (todos los hijos, ya sean inmediatos o no) y ancestors o ancestros (desde un
nodo hasta el raz, sin contar dicho nodo).

Existen una serie de condiciones que se pueden utilizar para filtrar el contenido:

o Existencia de un hodo hijo: crucero[marinero]/yate (Si existe un crucero que tiene
un hijo marinero, y adems un hijo yate... , es decir, yate y marinero son hermanos.
Dentro del corchete tambin permite poner un path: crucero[yate/marinero]/yate).

o Valor de un nodo: crucero[precio<1000] (Si existe un crucero que tiene un hijo
precio cuyo valor es menor de 1000...).

o Existencia de un atributo: crucero[@estado] (Si existe un crucero con un atributo
estado...).

o Valor de un atributo: crucero[@estado=disponible] (Si existe un crucero con un
atributo estado con valor disponible...).

o Se pueden hacer combinaciones de las anteriores opciones.

Operadores lgicos:

o And: [@id and @estado] (Si tiene un atributo y otro...).

o Or: [@id or @estado] (Si tiene un atributo u otro...).

o Unin: <xsl:template match=yate | marinero> (Un elemento y otro...).

Operaciones aritmticos:

o count(): <xsl:value-of select=count(crucero)/> <xsl:value-of
select=count(//crucero[precio<680])/> (Funcin que nos dice el nmero de nodos
que hay respecto al nodo en el que estamos colocado cumpliendo unas condiciones).

o *: precio * 3 (multiplica).

61 de 137

o +: precio + 1000 (suma).

o -: precio-@descuento (resta).

o Para dividir no se usa / porque sta ya posee una funcin, en su lugar se utiliza la
funcin div().

Por lo tanto tambin se puede hacer una identificacin por atributos:


Cuando encuentre un elemento
crucero...

<xsl:template match=crucero[@estado]>

crucero que tiene un atributo
llamado estado...

<xsl:template match=crucero[@estado=disponible]>

crucero que tiene un atributo
llamado estado y su valor es
disponible...

Para la presentacin de valores y atributos se utiliza la sentencia <xsl:value-of
select=/>:
<xsl:value-of select=@estado/> (si es un atributo)
<xsl:value-of select=puertosalida/> (si es un elemento)

Tambin se puede identificar por posiciones (utilizando las funciones position() y last()):

=puerto[position()=1]

Es cierto si:
- El nodo puerto existe y es un
nodo elemento.
- La expresin position()=1 es
evaluada y el resultado es true.

=puerto[position()=last()]

Es cierto si:
- El nodo puerto existe y es un
nodo elemento.
- La expresin position()=last()
es evaluada y el resultado es
true.

62 de 137

Ejemplo: Si tuvisemos elementos puerto que nos indicara todos los puertos en los que se
hace escala de un crucero y queremos identificarlos por posiciones:

<xsl:template match=ruta[puerto[position()=1]=PATRAS]>
<BR/>
La ruta comienza en PATRAS y finaliza en:
<xsl:value-of select=puerto[last()]/>
</xsl:template>

Con las funciones anteriores se pueden utilizar = y !=, pero no <, ni > entre valores
aunque s entre funciones. En su lugar, para nmeros se utilizan < y >:

position()=2
position()<last()
last()!=PATRAS
position()<3

Hay otras funciones tiles adems de count(), position() o last(), como puede ser not()
(para ver ms funciones leer captulo 14 de la Biblia del XML): sta nos devuelve, si es un
elemento o un atributo lo que contiene entre parntesis: si existe o no, y si es una sentencia: si
se da o no.

Ejemplos de expresiones XPath:

Expresin Descripcin
crucero[not(@estado)] | crucero[@estado=disponible]

Identifica los cruceros que no tienen atributo estado o
los cruceros donde el atributo estado tiene el valor
disponible.

@precio-@descuento

El valor del atributo precio menos el valor del atributo
descuento.

$X+1

Resultado de sumar 1 a la variable $X

@ancho=@alto

Comprueba si el valor del atributo ancho y el valor del
atributo alto son iguales.

(//seccion | //subseccion) [titulo=Introduccion]

Una expresin de unin entre parntesis. Selecciona
ambos, cualquier elemento que sea seccin y
subseccin si tienen un hijo llamado titulo con valor
introduccion.

//comment()

Selecciona todos los nodos comments que existan
dentro del documento.

63 de 137

crucero[yate=VENTANA][1]

Selecciona el primer crucero realizado con el yate
VENTANA.

crucero[1][yate=VENTANA]

Igual que el anterior ejemplo.

marinero[1]

El primer elemento hijo marinero en el contexto del
nodo.

marinero[last]

ltimo elemento hijo marinero en el contexto del nodo.

marinero[position()!=1]

Todos los elementos hijos excepto el primero.

//seccion/subseccion[1]

Todos los elementos subseccion que son el primer hijo
donde el padre es seccion.

(//seccion/subseccion)[1]

El primer elemento de un documento que tiene un hijo
subseccion con elemento padre seccion.

last()-1

La posicin anterior a la ltima en el contexto actual.

position()<last() div 2
Cierto si la posicin actual es menos de la mitad del
contexto.

REGLA APPLY-TEMPLATES

Con esta regla seleccionamos los elementos a los que vamos a aplicar alguna plantilla.
Tenemos que tener en cuenta que podemos seleccionar tanto los hijos del nodo en el que nos
encontremos o a otros que no son hijos del nodo actual:

<xsl:template match=ruta>
<xsl:apply-templates select=puerto/>
</xsl:template>

La aplica a todos los hijos de ruta con
nombre puerto.

<xsl:apply-templates select=puerto/>
<xsl:apply-templates select=//catalogo/crucero/marinero/>
</xsl:template>
La aplica a todos los hijos de ruta con
nombre puerto y a todos los nodos
marinero que son hijos de crucero y
nietos de catalogo que estn en cualquier
posicin del rbol.

EJEMPLO: Si tenemos el siguiente documento XML:

<catalogo>
<descripcion>Crucero entre las dos ciudades ms importante de Grecia.</descripcion>

64 de 137

<yate>HELLAS CRUSSADERS</yate>
<ruta>
<puerto>SALNICA</puerto>
<puerto>VOLOS</puerto>
<puerto>ATENAS</puerto>
</ruta>
</crucero>
<crucero>
<descripcion>Crucero por las islas griegas.</descripcion>
<yate>FLYING GREEKMAN</yate>
<ruta>
<puerto>KORFU</puerto>
<puerto>PATRAS</puerto>
<puerto>ZAKYNTHOS</puerto>
<puerto>KALAMATA</puerto>
<puerto>RHODES</puerto>
</ruta>
</crucero>
<crucero estado="disponible">
<precio>87</precio>
<descripcion>Crucero en el atlntico.</descripcion>
<yate>CARMEN</yate>
<ruta>
<puerto>AZORES</puerto>
<puerto>GOMERA</puerto>
<puerto>LANZEROTE</puerto>
<puerto>GRAN CANARIA</puerto>
</ruta>
</crucero>
<descripcion>Crucero por el caribe.</descripcion>
<yate>AQUIVA</yate>
<ruta>
<puerto>SANTA LUCIA</puerto>
<puerto>SANTA LUCIA</puerto>
</ruta>
</crucero>
<crucero>
<descripcion>Crucero por el norte de Europa.</descripcion>
<yate>ELYSION</yate>
<ruta>
<puerto>BILBO</puerto>
<puerto>PORTSMOUTH</puerto>
<puerto>COPENHAGE</puerto>
<puerto>OSLO</puerto>
</ruta>
</crucero>
<crucero>
<descripcion>Crucero por el mar Adritico.</descripcion>
<yate>CRISMADA</yate>
<ruta>
<puerto>SAN GIORGIO DE NOGARO</puerto>
<puerto>DUBROVNIK</puerto>
</ruta>
</crucero>
<crucero>
<descripcion>Crucero por oceana.</descripcion>
<yate>THE OLD FORT</yate>
<ruta>
<puerto>SIDNEY</puerto>
<puerto>HAWAII</puerto>
</ruta>
</crucero>
</catalogo>

65 de 137

a) El documento XSL para presentar el contenido del atributo estado:
<html>
<head>
<title>C R U C E R O S</title>
</head>
<body style="background:navy; font-family:verdana;">
<xsl:apply-templates select="catalogo"/>
</body>
</html>
</xsl:template>

<xsl:template match="catalogo">
<table align="center" bgcolor="#F3EDE0" border="0" style="font-size:10pt;">
<tr>
<td align="center" bgcolor="#E6E5E5">
<b>PRECIO</b>
</td>
<b>DESCRIPCIN DEL CRUCERO</b>
</td>
<b>NOMBRE DEL YATE</b>
</td>
<b>RUTA</b>
</td>
<b>ESTADO</b>
</td>
</tr>
<xsl:apply-templates select="crucero"/>
</table>
</xsl:template>

<xsl:template match="crucero">
<tr>
<td align="center" bgcolor="#DFE8EC">
<xsl:value-of select="precio"/>$
</td>
<td bgcolor="#DFE8EC">
<xsl:value-of select="descripcion"/>
</td>
<xsl:value-of select="yate"/>
</td>
<xsl:apply-templates select="ruta"/>
</td>
<xsl:value-of select="@estado"/>
</td>
</tr>
</xsl:template>

<xsl:template match="ruta">
<table align="center" style="font-size:10pt;">
<xsl:apply-templates select="puerto"/>
</table>
</xsl:template>

<xsl:template match="puerto">
<tr>
<td align="center">
<xsl:value-of select="."/>
</td>
</tr>

66 de 137
</xsl:template>
</xsl:stylesheet>

b) El documento XSL para presentar los datos de los cruceros donde el atributo estado
tenga valor:
<html>
<head>
</head>
</body>
</html>
</xsl:template>
<tr>
<b>PRECIO</b>
</td>
</td>
</td>
<b>RUTA</b>
</td>
<b>ESTADO</b>
</td>
</tr>
<xsl:apply-templates select="crucero[@estado]"/>
</table>
</xsl:template>

67 de 137
<xsl:template match="crucero[@estado]">
<tr>
</td>
</td>
</td>
</td>
</td>
</tr>
</xsl:template>

</table>
</xsl:template>

<xsl:template match="puerto">
<tr>
<td align="center">
</td>
</tr>
</xsl:template>
</xsl:stylesheet>

c) El documento XSL para presentar puertos de origen y destino del yate CARMEN:
<html>
<head>
</head>
</body>
</html>
</xsl:template>
<tr>
<b>PRECIO</b>

68 de 137

</td>
</td>
</td>
<b>RUTA</b>
</td>
<b>ESTADO</b>
</td>
</tr>
<xsl:apply-templates select="crucero[yate='CARMEN']"/>
</table>
</xsl:template>

<tr>
</td>
</td>
</td>
</td>
</td>
</tr>
</xsl:template>

</table>
</xsl:template>

<xsl:template match="puerto[position()=1]">
<tr>
<td align="right"><b>SALIDA</b></td>
<td>
</td>
</tr>
</xsl:template>

<xsl:template match="puerto[position()=last()]">
<tr>
<td align="right"><b>LLEGADA</b></td>
<td>
</td>
</tr>
</xsl:template>

<xsl:template match="puerto[(position()!=1) and (position()!=last())]">
<tr>
<td></td>
<td>
</td>
</tr>
</xsl:template>

</xsl:stylesheet>

69 de 137

5.5. ELEMENTOS XSLT.

5.5.1. <xsl:sort>

El XSL ofrece la posibilidad de ordenar los elementos gracias a <xsl:sort> usado con
<xsl:apply-templates> o <xsl:for-each>. Esta sentencia tiene los siguientes atributos:

o select: especifica el rea a ordenar; por defecto es ..
o order: puede ser ascendente (ascending) que es por defecto y descendente
(descending).
o lang: idioma de ordenacin.
o data-type: tipo de dato de la clave de ordenacin que puede ser no numrico (text)
[por defecto] o numerico (number).
o case-order: primero maysculas (upper-first) o primero minsculas (lower-first).

Ejemplo:

Aplica la plantilla a todos los nodos
crucero pero ordenndolos primero por
precio, y estos por nombre de puerto.
<xsl:apply-templates select=crucero>
<xsl:sort select=precio data-type=number/>
<xsl:sort select=ruta/puerto/>
</xsl:apply-templates>

5.5.2. <xsl:number>

Nos dice el orden real en el que se procesan los elementos en el documento. Esta funcin
no se altera aunque se utilice el <xsl:sort>. Algunos atributos son:

o level: puede ser single (en el mismo nivel), any (los niveles desde donde est hacia
abajo) y multiple (se mueve por diferentes niveles).
o count: lo que queremos contar.

70 de 137

o format: el formato en el que se nos presenta los nmeros. Puede tener los valores: i
(nmeros romanos en minsculas), I (nmeros romanos en maysculas), a (letras en
minsculas), A (letras en maysculas), 1 (formato decimal; est por defecto)...

Crucero nmero:
<xsl:number level=single count=crucero format=1/>
</xsl:template>

5.5.3. Bucles.

<xsl:for-each> Al igual que el <xsl:apply-templates> nos sirve para procesar los nodos
del rbol, aunque a diferencia de ste, con el <xsl:for-each> es menos clara la programacin,
pero es menos autmata ya que lo controlas ms. Debemos tener en cuenta, que el <xsl:for-
each> realiza desplazamiento y si vamos a referenciar a otro nodo diferente tenemos que
controlarlo. Tiene como atributo select, en donde se coloca la condicin del bucle; si solo se pone
el nombre de un elemento ejecuta todos los nodos que se llamen as:

<xsl:for-each select=puerto>
<li>
<xsl:value-of select=./>
</li>
</xsl:for-each>
</xsl:template>

5.5.4. Estructuras de decisin.

<xsl:if> es una condicin if simple que no admite else. Como atributo se puede utilizar
tanto test como match.
<xsl:if test=position()=1>
Puerto de salida: <xsl:value-of select=./>
</xsl:if>
</xsl:for-each>
</xsl:template>

71 de 137

<xsl:if test="ruta/puerto[(position()!=1) and (position()!=last())]">
</xsl:if>
</xsl:template>

<xsl:choose> nos permite crear bloques de decisin determinados por la clasula
<xsl:when>. Posee adems, <xsl:otherwise>, para los casos en que no se ejecuta ninguna
de las clasulas <xsl:when> especificadas.

<xsl:choose>
<xsl:when test=position()=1>
Puerto de salida: <xsl:value-of select=./>
</xsl:when>
<xsl:when test=position()=last()>
Puerto de llegada: <xsl:value-of select=./>
</xsl:when>
<xsl:otherwise>
Escala: <xsl:value-of select=./>
</xsl:otherwise
</xsl:choose>
</xsl:for-each>
</xsl:template>

5.5.5. Incorporacin de atributos a los elementos.

Nos puede ocurrir por ejemplo que queramos escribir una etiqueta HTML pero los atributos
no lo sepamos, sino que nos lo pasen a travs del documento XML. En este caso utilizamos la
sentencia <xsl:attribute> que incorpora atributos a los elementos XSL. Usa el atributo name
para indicar el nombre del atributo, y su valor ser lo que contenga entre sus etiquetas de inicio
y cierre.

<xsl:template match=foto>
<img>
<xsl:attribute name=src>
yates/<xsl:value-of select=./>
</xsl:attribute>
</img>
</xsl:template>

HTML: <img src=yate/carmen.jpg/>

72 de 137

<xsl:for-each select=crucero>
<a>
<xsl:attribute name=href>
#<xsl:value-of select=yate/>
</xsl:attribute>
<xsl:value-of select=yate/>
</a>
</xsl:for-each>

HTML: <a href=#carmen>carmen</a>

<a>
<xsl:attribute name=nombre>
<xsl:value-of select=../yate/>
</xsl:attribute>
</a>
<xsl:value-of select=..yate/>

HTML: <a name=carmen> ....</a>

Tambin podramos haber creado los elementos con <xsl:element>, as en lugar de poner
<a> y </a>, hubiramos puesto: <xsl:element name=a> y </xsl:element>.
5.5.6. <xsl:variable>

La sentencia <xsl:variable> nos permite definir variables. Tiene el atributo name que es
el nombre de la variable que creamos, y para darle el valor podemos usar select o asignndole lo
que contiene sus etiquetas de inicio y cierre. Para referenciarla despus usamos el nombre de la
variable precedido de $.

<xsl:variable name=precio select=//precio/>
....
Precio: <xsl:value-of select=$precio/>

<xsl:variable name="ID"><xsl:value-of select="dni"/></xsl:variable>

....

<xsl:for-each select="//empleado">
<xsl:sort select="ORDEN"/>
<xsl:if test="dni_padre=$ID">
<xsl:apply-templates select="."/>
</xsl:if>
</xsl:for-each>

73 de 137

<xsl:variable name=precio select=//precio/>
<hr/>
<xsl:value-of select=yate/>
Precio XML: <xsl:value-of select=precio/>
Variable precio: <xsl:value-of select=$precio/>
Suma: <xsl:value-of select=sum($precio)/>
</xsl:template>
La funcin sum() realiza el sumatorio de todos los
valores de los elementos que se referencian entre
parntesis.

Precio XML saca los valores reales de los elementos
XML.

Variable precio solo saca el valor del primer elemento
precio que se encuentra, y no cambia la variable de
valor, aunque internamente lo cambia y lo acumula
correctamente en la funcin sum(). Esto lo hace as
porque hemos utilizado //precio que coge siempre el
primer elemento, para refrescar la variable pondramos
<xsl:variable name=precio select=./precio/> o
<xsl:variable name=precio select=precio/>.

5.5.7. Comentarios.

Si queremos comentar algo en un documento XSL utilizamos . Estas etiquetas
no se procesan y por tanto no aparecen en el documento de salida. Si se desea que aparezcan
los comentarios se utiliza el elemento <xsl:comment>.



<xsl:comment>
Esto es un comentario que aparece en el documento de salida.
</xsl:comment>

5.5.8. <xsl:text>.

Si queremos que en el documento de salida nos aparezca texto podemos optar por utilizar
el elemento <xsl:text>, aunque existen otras alternativas mejores, como poner lo que se quiere
sin las etiquetas:
<xsl:text>hola</xsl:text> <font>hola </font>

Pero sin embargo si el texto del ejemplo anterior contiene caracteres especiales como
tildes, , &... nos da un error de documento mal formado. Para ello se utiliza el <xsl:text> en
combinacin del CDATA:

<font>
<xsl:text disable-output-escaping=yes>
<![CDATA[< Qué tal el tiempo en España >]]>

74 de 137

</xsl:text>
</font>

Con el atributo disable-output-escaping deshabilitamos la obtencin en la salida de dichos
caracteres. As la salida del ejemplo anterior ser: <Qu tal el tiempo en Espaa>

5.5.9. Scripts.

A travs de las sentencias <xsl:comment> y <![CDATA[ ]]> podremos aadir al
documento algn cdigo javascript, vbscript...

<script language=javascript>
<xsl:comment>
<![CDATA[
function ejecutar() {
if(document.comprar.haysize.value==si){
alert (debe seleccionar una talla);
}
}
]]>
</xsl:comment>
</script>

Aunque es muy frecuente que dentro del script necesitemos valores que nos lo pasen a
travs del XML, en este caso se utiliza <xsl:text> en lugar de <xsl:comment>:

<script language="JavaScript">
<xsl:text disable-output-escaping="yes">
<![CDATA[
variable1 = "valor1"+]]>
</xsl:text>
<xsl:value-of select="RESTO"/>
<xsl:text disable-output-escaping="yes">
<![CDATA[;
variable2 = 3;
]]>
</xsl:text>
</script>

75 de 137

Donde la variable1 se formara con valor1 y el valor de la etiqueta RESTO. Si esta ltima
contiene valor2, dara como resultado en HTML:

<script language="JavaScript">
variable1 = "valor1+ valor2;
variable2 = 3;
</script>

5.6. XML DATA ISLANDS (XML DSO).

El XML Data Island permite incorporar un documento XML dentro de una pgina HTML.
As podemos manejar datos de etiquetas XML en el propio HTML sin ningn tipo de
programacin. Esto es propiedad de Microsoft
y slo funciona con Internet Explorer 5.0.

Para reconocer el documento XML usamos: <XML ID= SRC= >, donde ID nos sirve
para identificarlo y SRC es el fichero XML. Con el atributo DATASRC dentro de la etiqueta
<body> o <table>, le decimos la fuente del documento XML (el ID). Para obtener el valor
usamos <SPAN DATAFLD= >, escribiendo el nombre del elemento en el atributo.

<HTML>
<HEAD><TITLE>HTML con XML Data Island</TITLE></HEAD>
<BODY>
<XML ID=xmlDoc SRC=yate.xml></XML>
<P>Esta pgina contiene un XML Data Island</P>
<TABLE BORDER=1 DATASRC=#xmlDoc>
<THEAD>
<TH>ID Yate</TH>
<TH>Nombre</TH>
</THEAD>
<TBODY>
<TD><SPAN DATAFLD=id></SPAN><TD>
<TD><SPAN DATAFLD=yate></SPAN><TD>
</TBODY>
</TABLE>
</BODY>
</HTML>

Para tener 2 hojas XML, habra que indicarle la fuente del documento XML antes de jugar
con los valores. El incoveniente que tiene el XML Data Island es que incrusta todos los datos sin
poder usar programacin.

76 de 137

5.7. XSL FORMATTING OBJECTS (XSL-FO).

(MS INFORMACIN EN CAPTULO 15 DE LA BIBLIA DE XML: FORMATEANDO OBJETOS
http://www.ibiblio.org/xml/books/bible/updates/15.html)

Como su propio nombre indica XSL-FO se utiliza para formatear el contenido de un
documento XML. Es decir, se le aplica un formato a los datos seleccionados por el XSL a partir de
los datos originales en XML. Por tanto, en el proceso de formateo adems de intervenir patrones
de bsqueda y transformacin (hoja de estilo), debe existir un convertidor o FOP, que es un
procesador de hojas de estilo capaz de interpretar XSL-FO y generar documentos formateados
como PDF.

Uno de los incovenientes del XSL-FO es que est en working-draft, pero es ms fcil que
XSLT.

Para utilizar XSL-FO le indicamos el namespace usado en el atributo xmlns:fo, y debemos
saber que una hoja XSL-FO posee regiones o reas:

Region:
- Contiene reas de tipo block u otras reas de tipo regin.
- Es un nivel ms alto en una XSL-FO.
- Un objeto formateado contiene las siguientes regiones: fo:region-body,
fo:region-before, fo:region-after, fo:region-start y fo:region-end.

Block:
- Contiene reas de tipo line, espacios de visualizacin, otras reas de tipo block
o reas de tipo regin.

Line:
- Representan una lnea de texto dentro de un block.
- Contiene reas de tipo inline o reas de espacios en blanco.
- Permite asociar atributos de tipo font.

Inline:
- Define cada uno de los caracteres o grficos dentro de una lnea.

<?xml version=1.0?>

77 de 137

<xsl:stylesheet
xmlns:xsl=http://www.w3.org/TR/WD-xsl
xmlns:fo=http://www.w3.org/TR/WD-xsl/FO>

<fo:display-sequence font-size=10pt font-family=serif>
</fo:display-sequence>
</xsl:template>

<fo:block font-size=12pt font-weight=bold>
</fo:block>
</xsl:template>

...

</xsl:stylesheet>

78 de 137

6. PROCESADORES / PARSERS XML.

6.1. PROCESO DE DOCUMENTOS XML.

De alguna forma necesitamos una herramienta para aplicar una hoja de estilo al documento
para poder visualizarlo y para validar el documento XML contra la DTD. No todos los parsers son
validantes a pesar de manejar DTDs, lo que si hacen todos es que los documentos estn bien
formados. Despus de utilizar el parser, podremos enviar el documento de salida a un
documento o a pantalla.

Este parser puede generar un rbol DOM o un handler del documento (parser SAX). La
diferencia es:

- el parser de DOM genera un rbol y nuestra programacin se basan en los movimientos
de ese rbol. Vamos a tener mtodos para movernos, extraer valores, generar hijos, ...

- el API de SAX considera el documento una cadena string, y su incoveniente es que
tenemos que programar los mtodos. Es decir, los mtodos ya estn definidos pero hay
que programar el funcionamiento de estos.

Desde el punto de vista de recursos, el DOM consume ms ya que ste construye un rbol
con todos los elementos del rbol, mientras que el SAX lo va haciendo a medida que ejecuta los
eventos, va cargando los elementos en memoria. Pero desde el punto de vista del manejo,
navegar por el rbol de DOM es mucho ms sencillo que con el SAX.

Existen muchos parsers: Project X (Sun Microsystems), lfred (Microstar Software), XML4J
(IBM), Lark (Tim Bray), MSXML (Microsoft), XJ (Data Channel), Xerces (Apache), XP (James
Clark), ...

6.2. Simple Api para Xml (SAX).

El API de SAX es un procesador de documento orientado a eventos, ya que va a ejecutar
eventos predefinidos: startDocument, startElement, characters, endElement, endElement. Al
DOM no lo llamamos, al SAX s; cuando llamamos al DOM, tenemos todos los mtodos; pero en
el SAX, al parser lo llamas t y le decimos lo que queremos al manipulador de documentos,
pues estn predeterminados los nombres de los mtodos pero no lo que tienen que hacer.

79 de 137

Existen 2 versiones de SAX actualmente: SAX 1.0 y SAX 2.0. Esta ltima ofrece funciones o
eventos que permiten modificar elementos del documento XML, que SAX 1.0 no las tiene.

Los paquetes que necesitamos para utilizarlos dentro de la clase java son org.xml.sax y
org.xml.sax.helpers.

Cuando el parser acta sobre el documento XML, se ejecutan los eventos:

startDocument: se ejecuta cuando empieza el documento.
startElement: se ejecuta por cada etiqueta de un elemento.
characters: permite recuperar el contenido de un elemento.
endElement: se ejecuta cuando encuentra la etiqueta de cierre de un elemento.
endDocument: sta lo hace al finalizar el documento, cuando ya no encuentra
ninguna informacin, no cuando encuentra la ltima etiqueta.

Automticamente con el manipulador de elementos, va llamando a cada uno de ellos pero
debemos indicarle qu debe hacer cada uno. Se le llama manipulador porque determina lo que
queremos hacer en cada elemento.

(Ms informacin en http://www.megginson.com/SAX/index.html)

6.3. Document Object Model (DOM).

El DOM proporciona un interface estndar para acceder y manipular estructuras XML
(dentro de lo que es la jerarqua hay que moverse hasta el valor del elemento). Manipula
documentos en forma de jerarqua de nodos, es independiente de la plataforma y del lenguaje de
programacin, es una recomendacin W3C y adems est incorporado en muchos parsers. Para
el DOM utilizamos el paquete org.w3.dom.

(Ms informacin en http://www.w3.org/DOM/)

80 de 137

ANEXO 1: RECOMENDACIN W3C febrero de 1998 (castellano).

EXTENSIBLE MARKUP LANGUAGE (XML) 1.0
RECOMENDACIN W3C 10 DE FEBRERO DE 1998
Esta versin:
http://www.w3.org/TR/1998/REC-xml-19980210
http://www.w3.org/TR/1998/REC-xml-19980210.xml
http://www.w3.org/TR/1998/REC-xml-19980210.html
http://www.w3.org/TR/1998/REC-xml-19980210.pdf
http://www.w3.org/TR/1998/REC-xml-19980210.ps
ltima versin:
http://www.w3.org/TR/REC-xml
Versin previa:
http://www.w3.org/TR/PR-xml-971208
Editores:
Tim Bray (Textuality y Netscape) <tbray@textuality.com>
Jean Paoli (Microsoft) <jeanpa@microsoft.com>
C. M. Sperberg-McQueen (University of Illinois at Chicago) <cmsmcq@uic.edu>

ABSTRACTO
El Lenguaje Extensible de Marcas (XML) es un subconjunto de SGML, que se describe completamente en este documento.
Sus objetivos son habilitar el SGML genrico para que pueda ser servido, recibido y procesado en la Web de la manera
que no es posible con HTML. XML ha sido diseado para facilitar la implementacin e interoperatividad con SGML y HTML.

ESTADO DE ESTE DOCUMENTO
Este documento ha sido revisado por los miembros del W3C y otras partes interesadas, y ha sido refrendada por el
Director como una Recomendacin W3C. Es un documento estable y puede ser utilizado como referencia o citado como
referencia normativa desde otros documentos. El papel del W3C al realizar la Recomendacin es el de potenciar a la
especificacin y promover su amplio despliegue. Este contribuye al incremento de la funcionalidad y la interoperatividad
de la Web.
Este documento especifica una sintaxis creada a partir de un estndar internacional de procesamiento de texto existente,
el Lenguaje Generalizado Estndar de Marcas (Standard Generalized Markup Language, ISO 8879:1986(E)) para su uso
en la World Wide Web. Es producto de la Actividad XML del W3C, de la que se pueden obtener detalles en
http://www.w3.org/XML. As mismo, puede obtenerse una lista de las actuales recomendaciones y otros documentos
tcnicos en http://www.w3.org/TR.
Esta especificacin utiliza el trmino URI, que es definido por [Berners-Lee et al.], en un trabajo en proceso denominado
[IETF RFC1738] as como en [IETF RFC1808].
La lista de erratas de esta especificacin est disponible en http://www.w3.org/XML/xml-19980210-errata (ingls).
EXTENSIBLE MARKUP LANGUAGE (XML) 1.0
NDICE DE CONTENIDOS
1. Introduccin
1.1 Origen y Objetivos
1.2 Terminologa
2. Documentos
2.1 Documentos XML Bien-Formados
2.2 Caracteres
2.3 Construcciones Sintcticas Comunes
2.4 Datos Carcter y Marcas
2.5 Comentarios
2.6 Instrucciones de Procesamiento
2.7 Secciones CDATA
2.8 Prolog y Declaracin de Tipo de Documento
2.9 Declaracin de Documento Standalone
2.10 Manejo de "Espacios en Blanco"
2.11 Manejo de "Fines de Lnea"

81 de 137
2.12 Identificacin del Lenguaje
3. Estructuras Lgicas
3.1 Etiquetas de Comienzo, Etiquetas de Fin, y Etiquetas de "Elementos-Vacos"
3.2 Declaraciones de Tipo de Elemento
3.2.1 Contenido del Elemento
3.2.2 "Contenido Mezclado"
3.3 Declaraciones de Listas de Atributos
3.3.1 Tipos de Atributos
3.3.2 Atributos por Defecto
3.3.3 Normalizacin de Atributos-Valor
3.4 Secciones Condicionales
4. Estructuras Fsicas
4.1 Referencias a Caracteres y Entidades
4.2 Declaraciones de Entidades
4.2.1 Entidades Internas
4.2.2 Entidades Externas
4.3 Entidades Analizadas
4.3.1 Declaracin de Texto
4.3.2 Entidades Analizadas Bien-Formadas
4.3.3 Codificacin de Caracteres en Entidades
4.4 Tratamiento de Entidades y Referencias por el Procesador XML
4.4.1 No Reconocidas
4.4.2 Incluidas
4.4.3 Incluidas si Validadas
4.4.4 Prohibidas
4.4.5 Incluidas en Literal
4.4.6 Notificar
4.4.7 Obviadas
4.4.8 Incluidas como PEs
4.5 Construccin de Texto de Reemplazo de Entidad Interna
4.6 Entidades Predefinidas
4.7 Declaraciones de Notacin
4.8 Entidad Documento
5. Conformancia
5.1 Procesadores Validadores y No Validadores
5.2 Utilizacin de Procesadores XML
6. Notacin

APNDICES
A. Referencias
A.1 Referencias Normativas
A.2 Otras Referencias
B. Clases de Caracteres
C. XML y SGML (No Normativo)
D. Expansin de Referencias a Entidades y Caracteres (No Normativo)
E. Modelos de Contenido Deterministas (No Normativo)
F. Autodeteccin de la Codificacin (No Normativo)
G. Grupo de Trabajo XML del W3C (No Normativo)

1. INTRODUCCIN
El Lenguaje Extensible de Marcas, abreviado XML, describe una clase de objetos de datos llamados documentos XML y
describe parcialmente el comportamiento de los programas de computadora que los procesan. XML es un "perfil de
aplicacin" o una forma restringida de SGML, el Lenguaje Estndar Generalizado de Marcacin [ISO 8879]. Por
construccin, los documentos XML son documentos SGML conformados.
Los documentos XML estn compuestos por unidades de almacenamiento llamadas entidades, que contienen tanto datos
analizados como no analizados. Los datos analizados estn compuestos de caracteres, algunos de los cuales, de la forma
datos carcter, y otros de la forma marca. Las marcas codifican una descripcin de la estructura de almacenamiento del
documento y su estructura lgica. XML proporciona un mecanismo para imponer restricciones al almacenamiento y a la
estructura lgica.
Se utiliza un mdulo software llamado procesador XML para leer documentos XML y proporcionar acceso a su contenido
y estructura. Se asume que un procesador XML hace su trabajo dentro de otro mdulo, llamado aplicacin. Esta
especificacin describe el comportamiento requerido de un procesador XML en trminos de cmo leer datos XML y la
informacin que debe proporcionar a la aplicacin.

82 de 137

1.1 ORIGEN Y OBJETIVOS
XML fue desarrollado por un Grupo de Trabajo XML (originalmente conocido como "SGML Editorial Review Board")
formado bajo los auspicios del Consorcio World Wide Web (W3C), en 1996. Fue presidido por Jon Bosak de Sun
Microsystems con la participacin activa de un Grupo Especial de Inters en XML (previamente conocido como Grupo de
Trabajo SGML) tambin organizado en el W3C. Los miembros del Grupo de Trabajo XML se especifican en un apndice.
Dan Connolly sirvi como contacto entre el GT y el W3C.
Los objetivos de diseo de XML son:
1. XML debe ser directamente utilizable sobre Internet.
2. XML debe soportar una amplia variedad de aplicaciones.
3. XML debe ser compatible con SGML.
4. Debe ser fcil la escritura de programas que procesen documentos XML.
5. El nmero de caractersticas opcionales en XML debe ser absolutamente mnima, idealmente cero.
6. Los documentos XML deben ser legibles por humanos y razonablemente claros.
7. El diseo de XML debe ser preparado rpidamente.
8. El diseo de XML debe ser formal y conciso.
9. Los documentos XML deben ser fcilmente creables.
10. La concisin en las marcas XML es de mnima importancia.
Esta especificacin, junto con los estndares asociados (Unicode e ISO/IEC 10646 para caracteres, Internet RFC 1766
para identificacin de lenguajes, ISO 639 para cdigos de nombres de lenguajes, e ISO 3166 para cdigos de nombres de
pases), proporciona toda la informacin necesaria para entender la Versin 1.0 de XML y construir programas de
computador que los procesen.
Esta versin de la especificacin puede ser distribuida libremente, siempre y cuando se mantengan intactos todos los
textos y trminos legales.

1.2 TERMINOLOGA
La terminologa utilizada para describir los documentos XML esta definida en el cuerpo de esta especificacin. Los
trminos definidos en la siguiente lista son utilizados en la construccin de esas definiciones y en la descripcin de las
acciones del procesador XML:
poder
La conformacin de documentos y los procesadores de XML pueden permitirlo, pero no requieren ser soportados
tal y como se describen.
deber
La conformacin de documentos y los procesadores de XML deben soportarlo tal y como se describe, de otro
modo son errneos.
error
Una violacin de las reglas de esta especificacin, los resultados estn indefinidos. Los programas
conformadores deberan detectar e informar acerca de los errores y recuperarse de ellos.
error fatal
Un error que debe detectar un procesador XML e informar acerca de l a la aplicacin. Tras encontrar un error
fatal, el procesador tiene que continuar procesando los datos para buscar otros posibles errores y debera de
informar de los errores a la aplicacin. Para soportar la correccin de errores, el procesador debera hacer que
los datos no procesados del documento (con datos carcter y marcas) sean accesibles a la aplicacin. Una vez
que se detecta un error fatal, el procesador debe continuar el procesado normalmente (p.e. no debe continuar
pasando los datos carcter e informacin acerca de la estructura lgica del documento a la aplicacin).
opcin de usuario
Los programas conformadores pueden o deben (dependiendo del tiempo verbal de la frase) comportarse como
se describe. Si lo hacen, deben proporcionar mecanismos para deshabilitar el comportamiento descrito.
restriccin de validez
Una regla que se aplica a todo documento XML vlido. Las violaciones de la restriccin de validez son errores, y
los procesadores validadores de XML deben, por opcin de usuario, informar de ellas.
restriccin de buena-formacin

83 de 137

Una regla que se aplica a todo documento XML bien-formado. Las violaciones de la restriccin buena-formacin
son errores fatales.
igualdad
(de cadenas de caracteres o nombres:) Dos cadenas de caracteres o nombres a comparar deben ser idnticos.
Los caracteres con mltiples representaciones posibles en la norma ISO/IEC 10646 (p.e. los caracteres con
formas precompuestas y los "base+diacritic") slo son comparables si tienen la misma representacin en ambas
cadenas. Por opcin de usuario, los procesadores pueden normalizar estos caracteres a alguna forma cannica
(de cadenas de caracteres y reglas en la gramtica:) Una cadena de caracteres es igual a una produccin
gramatical si pertenece al lenguaje generado por esa produccin. (de contenido y modelos de contenido:) Un
elemento es igual a su declaracin cuando conforma las reglas descritas en la restriccin de "Validez de
Elemento".
por compatibilidad
Una caracterstica de XML incluida nicamente para asegurar que XML permanece compatible con SGML.
por interoperatividad
Una recomendacin no obligatoria incluida para incrementar las funcionalidades de los documentos XML que
pueden ser procesados por la base instalada existente de procesador SGML que aadan las adaptaciones
WebSGML al ISO 8879.

2. DOCUMENTOS
Un objeto de datos es un documento XML si esta bien-formado, tal y como se define en esta especificacin. Un
documento XML bien-formado puede adems ser vlido si cumple una serie de restricciones.
Todo documento XML posee una estructura lgica y una fsica. Fsicamente, el documento est compuesto de unidades
llamadas entidades. Una entidad puede hacer referencia a otras entidades para que stas sean incluidas en el
documento. Un documento comienza en una "raz" o entidad documento. Lgicamente, el documento est compuesto de
declaraciones, elementos, comentarios, referencias a caracteres e instrucciones de procesamiento, todos los cuales se
indican en el documento mediante marcas explcitas. Las estructuras lgica y fsica deben anidarse de manera correcta,
como se describe en el punto "4.3.2 Entidades Analizadas Bien-Formadas".

2.1 DOCUMENTOS XML BIEN-FORMADOS
Un objeto de texto es un documento XML bien-formado si:
1. Tomado como un todo, cumple la regla denominada document.
2. Respeta todas las restricciones de buena-formacin dadas en esta especificacin.
3. Cada una de las entidades analizadas que se referencia directa o indirectamente en el documento est bien-
formada.
Documento
[1] document ::= prolog element Misc*
Cumplir la produccin document implica que:
1. Contiene uno o ms elementos.
2. Hay exactamente un elemento, llamado raz, o elemento documento, del cual ninguna parte aparece en el
contenido de ningn otro elemento. Para el resto de elementos, si la etiqueta de comienzo est en el contenido
de algn otro elemento, la etiqueta de fin est en el contenido del mismo elemento. Es decir, los elementos
delimitados por etiquetas de comienzo y final, de anidan adecuadamente mutuamente.
Como consecuencia de esto, para cada elemento no raz H en el documento, existe otro elemento P tal que H est
contenido en P, pero no es el contenido de ningn otro elemento que est en el contenido de P. P es denominado padre
de H, y H es hijo de P.

2.2 CARACTERES
Una entidad analizada contiene texto, una secuencia de caracteres, que pueden representar marcas o datos carcter. Un
carcter es una unidad atmica de texto como se especifica en la norma ISO/IEC 10646 [ISO/IEC 10646]. Los
caracteres legales son los tabuladores, retornos de carro, finales de lnea y los caracteres grficos legales del estndar

84 de 137

Unicode y de la norma ISO/IEC 10646. La utilizacin de "compatibilidad de caracteres", como se define en la seccin 6.8
de [Unicode], no est contemplada.
Rango de Caracteres
[2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-
#xFFFD] | [#x10000-#x10FFFF]
/* cualquier carcter Unicode, excluyendo los
bloques subrogados FFFE y FFFF. */
Los mecanismos para codificar los cdigos de caracteres en patrones de bits pueden variar de una entidad a otra. Todos
los procesadores XML deben aceptar las codificaciones UTF-8 y UTF-16 de la norma ISO/IEC 10646. El mecanismo para
sealar cual de las dos est en uso, o para definir otras codificaciones, se discutir ms abajo en la seccin
"4.3.3 Codificacin de Caracteres en Entidades".

2.3 CONSTRUCCIONES SINTCTICAS COMUNES
Esta seccin define algunos smbolos utilizados en la gramtica.
El smbolo S (espacio en blanco) est compuesto de uno o ms caracteres espacio (#x20), retornos de carro, finales de
lnea o tabuladores.
Espacios en Blanco
[3] S ::= (#x20 | #x9 | #xD | #xA)+
Los caracteres se clasifican, por conveniencia, en letras, dgitos u otros caracteres. Las letras se componen de caracteres
de base alfabtica o silbica, seguidos de uno o ms caracteres combinatorios, o caracteres ideogrficos. Las
declaraciones completas de cada clase de caracteres se da en "B. Clases de Caracteres".
Un Nombre es un "token" que comienza con una letra o uno o ms caracteres de puntuacin, y que continua con letras,
dgitos, guiones, subrayados, comas y/o puntos. Los Nombres que comienzan por la cadena "xml", o cualquiera que
cumpla la regla (('X'|'x') ('M'|'m') ('L'|'l')), quedan reservados para estandarizacin en esta o futuras versiones de esta
especificacin.
Nota: El carcter dos puntos en los nombres XML est reservado para la experimentacin con espacios de nombres. Se
prev que se estandarizar su significado en un futuro, en el que los documentos que utilicen este carcter con
propsitos experimentales debern ser actualizados. (No existe garanta de que se adopte el mecanismo de espacios de
nombres para XML). En la prctica, esto significa que los autores no deberan utilizar los dos puntos en XML, excepto
como parte de espacios de nombres experimentales. Sin embargo los procesadores XML deben aceptar este carcter en
los Nombres.
Un "Nmtoken" (name token) es cualquier combinacin de caracteres de nombre.
Nombres y "Tokens"
[4] NameChar ::= Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar | Extender
[5] Name ::= (Letter | '_' | ':') (NameChar)*
[6] Names ::= Name (S Name)*
[7] Nmtoken ::= (NameChar)+
[8] Nmtokens ::= Nmtoken (S Nmtoken)*
Los datos literales consisten en cualquier cadena entrecomillada que no contenga el tipo de comillas utilizadas como
delimitadores en la propia cadena. Los literales se utilizan para especificar el contenido de entidades internas
("EntityValue"), los valores de los atributos ("AttValue") y los identificadores externos ("SystemLiteral"). Hay que tener
en cuenta que el smbolo "SystemLiteral" puede ser analizado sin tomar en cuenta la presencia de marcas.
Literales
[9] EntityValue ::= '"' ([^%&"] | PEReference | Reference)* '"'
|"'" ([^%&'] | PEReference | Reference)* "'"
[10] AttValue ::= '"' ([^<&"] | Reference)* '"'
| "'" ([^<&'] | Reference)* "'"
[11] SystemLiteral ::= ('"' [^"]* '"') | ("'" [^']* "'")

85 de 137

[12] PubidLiteral ::= '"' PubidChar* '"' | "'" (PubidChar - "'")* "'"
[13] PubidChar ::= #x20 | #xD | #xA | [a-zA-Z0-9] | [-'()+,./:=?;!*#@$_%]

2.4 DATOS CARCTER Y MARCAS
El Texto consiste en datos carcter y marcas entremezcladas. Las Marcas toman la forma de etiquetas de comienzo,
etiquetas de fin, etiquetas de elementos vacos, referencias a entidades, referencias a caracteres, comentarios, secciones
CDATA delimitadores, declaraciones de tipo de documento e instrucciones de procesamiento.
Todo texto que no sea una marca constituye los denominados datos carcter del documento.
El carcter "ampersand" (&) y el parntesis angular de apertura (<) pueden aparecer de forma literal slo cuando se
utilicen como delimitadores de marcas, o dentro de los comentarios, en instrucciones de procesamiento, o en secciones
CDATA. Tambin pueden utilizarse en los valores literales de entidad de una declaracin de entidad interna; ver
"4.3.2 Entidades Analizadas Bien-Formadas". Si son necesarios en cualquier otro punto, deben ser "escapados" mediante
la utilizacin de referencias numricas a caracteres, o mediante las cadenas "&" y "<" respectivamente. El
parntesis angular de cierre (>) puede ser representado utilizando la cadena ">", y debe, por compatibilidad, ser
"escapado" utilizando ">" o la referencia a carcter cuando aparece como contenido de la cadena "]]>", siempre y
cuando la cadena no marque el final de una seccin CDATA.
En el contenido de los elementos, los datos carcter son cualquier cadena de caracteres que no contenga el delimitador
de comienzo de marca. En las secciones CDATA, los datos carcter son aquellos que no se incluyan en el delimitador de
fin de seccin CDATA, "]]>".
Para permitir que los valores de los atributos puedan contener tanto las comillas simples como las dobles, el carcter
apstrofe o comilla simple (') puede ser representado como "'", y el comilla doble (") como """.
Datos Carcter
[14] CharData ::= [^<&]* - ([^<&]* ']]>' [^<&]*)

2.5 COMENTARIOS
Los Comentarios pueden aparecer en cualquier punto del documento, fuera del resto de marcas; adems, pueden
aparecer en la declaracin de tipo de documento, en los lugares permitidos por la gramtica. No son parte de los datos
carcter del documento. Un procesador XML puede, pero no debe, permitir a la aplicacin obtener el texto de los
comentarios. Por compatibilidad, la cadena "--" (dos guiones) no puede aparecer dentro de un comentario.
Comentarios
[15] Comment ::= ''
Un ejemplo de comentario:


2.6 INSTRUCCIONES DE PROCESAMIENTO
Las Instrucciones de Procesamiento (PIs) permiten a los documentos contener instrucciones para las aplicaciones.
Instrucciones de Procesamiento
[16] PI ::= '<?' PITarget (S (Char* - (Char* '?>' Char*)))? '?>'
[17] PITarget ::= Name - (('X' | 'x') ('M' | 'm') ('L' | 'l'))
Las PIs no son parte de los datos carcter del documento, pero deben ser pasadas a la aplicacin. Las PIs empiezan con
un destino (PITarget) utilizado para identificar a la aplicacin a la que est dirigida dicha instruccin. Los nombres de

86 de 137

destino "XML", "xml", y las combinaciones de maysculas y minsculas a partir de stas, estn reservados para
estandarizacin en esta o futuras versiones de esta especificacin. El mecanismo de Notacin XML puede ser utilizado
para la declaracin formal de destinos de PIs.

2.7 SECCIONES CDATA
Las secciones CDATA pueden aparecer all donde pueden aparecer los datos carcter. Se utilizan para "escapar"
bloques de texto que contengan caracteres que de otra forma se reconoceran como marcas. Las secciones CDATA
comienzan por la cadena "<![CDATA[" y terminan con la cadena "]]>":
Secciones CDATA
[18] CDSect ::= CDStart CData CDEnd
[19] CDStart ::= '<![CDATA['
[20] CData ::= (Char* - (Char* ']]>' Char*))
[21] CDEnd ::= ']]>'
En una seccin CDATA slo la cadena CDEnd se reconoce como marca, por lo tanto, el parntesis angular de apertura y el
carcter "ampersand" pueden aparecer de forma literal, es decir, no necesitan (y no pueden) ser "escapados" mediante
"<" ni "&". No se pueden anidar las secciones CDATA.
Veamos un ejemplo de seccin CDATA, en el cual "<saludo>" y "</saludo>" son reconocidos como datos carcter, y no
como marcas:
<![CDATA[<saludo>Hola, mundo!</saludo>]]>

2.8 PROLOG Y DECLARACIN DE TIPO DE DOCUMENTO
Los documentos XML pueden, y deberan, comenzar con una declaracin XML que especifica la versin de XML
utilizada. Por ejemplo, el siguiente es un documento XML completo, bien-formado pero no vlido:
<saludo>Hola, mundo!</saludo>
y tambin lo es:
El nmero de versin "1.0" debera utilizarse para indicar la conformancia a esta versin de la especificacin. Se produce
un error si un documento utiliza el valor "1.0" y ste no conforma la especificacin de esta versin. Es intencin del
Grupo de Trabajo XML el proveer de nuevos nmeros versiones de esta especificacin, pero no se asegura que habrn
futuras versiones de XML. Dado que no se han regulado futuras versiones, esta construccin se ha permitido para
posibilitar el reconocimiento automticamente de la versin, si fuese necesario. Los procesadores deben indicar que
existe un error si reciben un documento etiquetado con una versin que no soportan.
La funcin de las marcas en los documentos XML reside en describir su almacenamiento y estructura lgica, as como
asociar pares atributo-valor con dicha estructura lgica. XML proporciona un mecanismo, la declaracin de tipo de
documento, para definir restricciones sobre las estructuras lgicas y para contemplar el uso de unidades de
almacenamiento predefinidas. Un documento XML es vlido si tiene asociada una declaracin de tipo de documento y si
el documento cumple las restricciones que all se expresan.
La declaracin de tipo documento debe aparecer antes que el primer elemento en el documento.
Prolog
[22] prolog ::= XMLDecl? Misc* (doctypedecl Misc*)?
[23] XMLDecl ::= '<?xml' VersionInfo EncodingDecl? SDDecl? S? '?>'
[24] VersionInfo ::= S 'version' Eq (' VersionNum ' | " VersionNum ")
[25] Eq ::= S? '=' S?
[26] VersionNum ::= ([a-zA-Z0-9_.:] | '-')+

87 de 137

[27] Misc ::= Comment | PI | S
La declaracin de tipo de documento XML, contiene o describe declaraciones de marcas que proporcionan una
gramtica para una clase de documentos. Esta gramtica se conoce como definicin de tipo de documento o DTD. La
declaracin de tipo de documento puede referirse a un subconjunto externo (un tipo especial de entidad externa) que
contiene declaraciones, o puede contener las declaraciones de marcas directamente en un subconjunto interno, o puede
hacer ambos. Una DTD para un documento consiste en la unin de ambos subconjuntos.
Una declaracin de marcacin es una declaracin de tipo de elemento, una declaracin de lista de atributos, una
declaracin de entidad, o una declaracin de notacin. Estas declaraciones pueden estar contenidas en su totalidad o en
parte en las entidades parmetro, como se describe en las restricciones de buena-formacin y validez. Para ms
informacin al respecto, ver la seccin "4. Estructuras Fsicas".
Definicin de Tipo de Documento
[28] doctypedecl ::= '<!DOCTYPE' S Name (S ExternalID)? S? ('['
(markupdecl | PEReference | S)* ']' S?)? '>'
[ RV: Tipo de Elemento Raz ]
[29] markupdecl ::= elementdecl | AttlistDecl | EntityDecl | NotationDecl | PI
| Comment
[ RV: Declaracin
Apropiada/Anidamiento de PEs ]
[ RBF: PEs en Subconj Interno ]
La declaracin de marcas puede estar constituida totalmente o en parte de texto de reemplazo de entidades parmetro.
Las reglas de produccin que aparecern en esta especificacin para los no terminales individuales (elementdecl,
AttlistDecl, etc.) describen las declaraciones despus de que todas las entidades parmetro hayan sido incluidas.
Restriccin de Validez: Tipo de Elemento Raz
El Nombre (Name) en la declaracin de tipo de documento debe ser igual al tipo de elemento del elemento raz.
Restriccin de Validez: Declaracin Apropiada/Anidamiento de PEs
El texto de reemplazo de la entidad parmetro debe estar anidado apropiadamente dentro de la declaracin de marcas.
Es decir, si el primer o el ltimo carcter en la declaracin de una marca (markupdecl arriba) est contenido en el texto
de reemplazo para una referencia a entidad parmetro, ambos deben estar contenidos en el mismo texto de reemplazo.
Restriccin de Buena-Formacin: PEs en el Subconjunto Interno
En el subconjunto del DTD interno, las referencias a entidades parmetro slo pueden aparecer donde puedan aparecer
las declaraciones de marcas, nunca dentro de las declaraciones de marcas. (Esto no se aplica a las referencias que
aparecen en entidades parmetro externas o en el subconjunto externo.)
Como en el subconjunto interno, el subconjunto externo y cualquier entidad parmetro externa referenciada en el DTD
debe consistir de una serie de declaraciones completas de marcas de los tipos permitidos por el smbolo no-terminal
markupdecl, intercaladas con espacios en blanco o referencias a entidades parmetro. Sin embargo, porciones de los
contenidos del subconjunto externo o de las entidades parmetro externas pueden ser ignoradas condicionalmente
mediante la utilizacin de la construccin seccin condicional; esto no est permitido en el subconjunto interno.
Subconjunto Externo
[30] extSubset ::= TextDecl? extSubsetDecl
[31] extSubsetDecl ::= ( markupdecl | conditionalSect | PEReference | S )*
El subconjunto externo y las entidades parmetro externas tambin difieren del subconjunto interno en que en ellos, las
referencias a entidades parmetro son permitidas dentro de las declaraciones de marcas, no slo entre de ellas.
Un ejemplo de un documento XML con una declaracin de tipo de documento:
<!DOCTYPE saludo SYSTEM "hola.dtd">
El identificador de sistema "hola.dtd" proporciona el URI de una DTD para el documento.
Las declaraciones pueden tambin darse localmente, como es este ejemplo:
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE saludo [
<!ELEMENT saludo (#PCDATA)>
]>

88 de 137

En ambos se utilizan tanto en el subconjunto interno, como en el externo. El interno se considera que aparezca antes que
el externo. Esto indica que las declaraciones de entidades y de listas de atributos en el subconjunto interno toman
precedencia sobre las de externo.

2.9 DECLARACIN DE DOCUMENTO STANDALONE
Las declaraciones de marcas pueden afectar al contenido de un documento, como cuando se pasan de un procesador XML
a una aplicacin; un ejemplo de esto son los valores por defecto de los atributos y las declaraciones de entidades. La
declaracin de documento standalone, que puede aparecer como componente de la declaracin XML, seala si existen o
no dichas declaraciones que aparecen externamente a la entidad documento.
Declaracin de Documento Standalone
[32] SDDecl ::= S 'standalone' Eq (("'" ('yes' | 'no') "'") | ('"' ('yes' | 'no')
'"'))
[ RV: Declaracin de Documento
Standalone ]
En la declaracin de documento standalone, el valor "yes" indica que no existen declaraciones de marcas externas a la
entidad documento (ni en el subconjunto externo del DTD, ni en una entidad parmetro externa referenciada desde el
subconjunto interno) que afecte a la informacin pasada desde el procesador XML a la aplicacin. El valor "no" indica que
existe o que pueden haber dichas declaraciones externas de marcas. La declaracin de documento standalone slo
denota la presencia de declaraciones externas; la presencia, en un documento, de referencias a entidades externas,
cuando esas entidades son declaradas internamente, no cambia el estado standalone del documento.
Si no existen declaraciones externas de marcas, la declaracin de documento standalone no tiene sentido. Si, por el
contrario, existiesen, pero no hay ninguna declaracin de documento standalone, se asume el valor "no".
Cualquier documento XML para el cual standalone="no" puede convertirse algortmicamente en un documento
standalone, el cual puede ser necesario para algunas aplicaciones de envo en un entorno de redes.
Restriccin de Validez: Declaracin de Documento Standalone
La declaracin de documento standalone debe tener el valor "no" si cualquier declaracin externa de marcas contiene:
atributos con valores por defecto, si los elementos a los que se aplican esos atributos aparecen en el documento
sin especificaciones de valores para esos atributos, o
entidades (que no sean amp, lt, gt, apos, quot), si las referencias a esas entidades aparecen en el documento, o
atributos con valores sujetos a normalizacin, donde el atributo aparece en el documento con un valor que
cambiar como resultado de la normalizacin, o
tipos de elementos con contenido de elemento, si aparecen espacios en blanco directamente dentro de cualquier
instancia de esos tipos.
Un ejemplo de declaracin XML con una declaracin de documento standalone:
<?xml version="1.0" standalone='yes'?>

2.10 MANEJO DE "ESPACIOS EN BLANCO"
En la edicin de documentos XML, suele ser conveniente utilizar "espacios en blanco" (espacios, tabuladores y lneas en
blanco, denotadas por el no terminal S en esta especificacin) para mantener la legibilidad de las marcas. Generalmente
estos caracteres no deben incluirse en una posible versin distribuible del documento a travs de una red. Por otro lado,
existen ocasiones en las que es deseable la existencia de esos "espacios", por ejemplo en poesa y en la representacin
de cdigo fuente.
Un procesador XML debe pasar siempre todos los caracteres de un documento, que no sean marcas, a la aplicacin. Un
procesador XML validador debe informar tambin a la aplicacin acerca de los caracteres que constituyen los "espacios en
blanco" contenidos en el contenido del elemento.

89 de 137

Un atributo especial denominado xml:space puede ser adjuntado a un elemento para sealar la necesidad de mantener
los caracteres "espacio" en dicho elemento. Los "espacios" deben ser preservados por las aplicaciones. En los
documentos vlidos, este atributo, como cualquier otro, debe ser declarado si se utiliza. Cuando se declara, debe darse
como un tipo enumerado cuyo nico valor posible es "default" y "preserve". Por ejemplo:
<!ATTLIST poema xml:space (default|preserve) 'preserve'>
El valor "default" indica que el procesamiento por defecto por parte de las aplicaciones de los "espacios en blanco" es
aceptable para este elemento. El valor "preserve" indica que las aplicaciones deben preservar todos los "espacios en
blanco". Esta declaracin se considera aplicable a todos los elementos dentro del contenido del elemento donde esta
especificada, salvo que se anule con otra instancia del atributo xml:space.
Se considera que el elemento raz de los documento, por defecto, no requiere el manejo especial de "espacios" de la
aplicacin, si no tiene declarado este atributo.

2.11 MANEJO "FINES DE LNEA"
Las entidades analizadas XML son frecuentemente almacenadas en archivos de ordenador, y por conveniencia de edicin,
estn organizados en lneas. Estas lneas estn tpicamente separadas por una combinaciones de caracteres formada por
"retorno de carro" (#xD) y "fin de lnea" (#xA).
Para simplificar las tareas de las aplicaciones, bien sea una entidad analizada externa o una entidad valor literal de una
entidad analizada interna, ambas contienen la secuencia literal de dos caracteres "#xD#xA" o un nico literal #xD. Un
procesador XML debe pasar nicamente a la aplicacin el carcter #xA. (Este comportamiento puede ser producido
mediante la normalizacin de todos los "fines de lnea" a caracteres #xA antes de ser analizados).

2.12 IDENTIFICACIN DEL LENGUAJE
En el procesado de documentos, suele ser til la identificacin entre el lenguaje natural o el lenguaje formal, en el que
est escrito el contenido. Un atributo especial denominado xml:lang puede ser insertado en los documentos para
especificar el lenguaje utilizado en los contenidos y los valores de atributos de cualquier elemento en un documento XML.
En los documentos vlidos, este atributo, como cualquier otro, debe ser declarado si se utiliza. Los valores de este
atributo son identificadores de lenguajes como los definidos en el documento [IETF RFC 1766], "Etiquetas para la
Identificacin de Lenguajes":
Identificacin de Lenguaje
[33] LanguageID ::= Langcode ('-' Subcode)*
[34] Langcode ::= ISO639Code | IanaCode | UserCode
[35] ISO639Code ::= ([a-z] | [A-Z]) ([a-z] | [A-Z])
[36] IanaCode ::= ('i' | 'I') '-' ([a-z] | [A-Z])+
[37] UserCode ::= ('x' | 'X') '-' ([a-z] | [A-Z])+
[38] Subcode ::= ([a-z] | [A-Z])+
La produccin Langcode puede ser cualquiera de las siguientes:
un cdigo de dos letras como se define en la norma [ISO 639], "Cdigos para la representacin de nombres de
lenguajes"
un identificador de lenguaje registrado con la Internet Assigned Numbers Authority [IANA]; stos comienzan con
el prefijo "i-" (o "I-")
un identificador de lenguaje asignado por el usuario, o convenido entre las partes en uso privado; stos deben
comenzar con el prefijo "x-" o "X-", de manera que se asegure que no entran en conflicto con nombres que
puedan ser estandarizados o registrados por la IANA
Puede haber cualquier nmero de segmentos Subcode. Si el primer segmento de subcdigo existe y ese subcdigo
consiste en dos letras, ste debe pertenecer al cdigo de un pas de la norma [ISO 3166], "Cdigos para la
representacin de nombres de pases". Si el primer subcdigo contiene ms de dos letras, ste debe ser un subcdigo
para el lenguaje en cuestin, registrado por la IANA, a no ser que Langcode comience por el prefijo "x-" o "X-".

90 de 137

Se suele acordar dar el cdigo del lenguaje en minsculas, y el cdigo del pas (si tuviese) en maysculas. Hay que
resaltar que estos valores, a diferencia del resto de nombres en XML, son representables indistintamente en minsculas o
en maysculas.
Por ejemplo:
<p xml:lang="en">The quick brown fox jumps over the lazy dog.</p>
<p xml:lang="en-GB">What colour is it?</p>
<p xml:lang="en-US">What color is it?</p>
<sp who="Faust" desc='leise' xml:lang="de">
<l>Habe nun, ach! Philosophie,</l>
<l>Juristerei, und Medizin</l>
<l>und leider auch Theologie</l>
<l>durchaus studiert mit heiem Bemh'n.</l>
</sp>
El atributo xml:lang declarado se considera que debe aplicarse a todos los atributos y al contenido de los elementos
donde esta especificado, a no ser que sea anulado por otra instancia de xml:lang en otro elemento de ese contenido.
Una simple declaracin para xml:lang puede tomar la forma:
xml:lang NMTOKEN #IMPLIED
pero tambin pueden darse los valores por defecto especficos. En una coleccin de poemas franceses para estudiantes
ingleses, con notas en ingls, el atributo xml:lang puede ser declarado de la siguiente manera:
<!ATTLIST poema xml:lang NMTOKEN 'fr'>
<!ATTLIST anotacin xml:lang NMTOKEN 'en'>

3. ESTRUCTURAS LGICAS
Cada documento XML contiene uno o ms elementos, cuyos lmites estn delimitados por etiquetas de comienzo y
etiquetas de fin, o en los elementos vacos, por una etiqueta de elemento vaco. Cada elemento tiene un tipo, identificado
por un nombre, a veces denominado "identificador genrico" (GI: Generic Identifier), y puede tener un conjunto de
especificaciones de atributos. Cada una de stas tiene un nombre y un valor.
Elemento
[39] element ::= EmptyElemTag
| STag content ETag [ RBF: Igualdad de Tipo de Elemento ]
[ RV: Elemento Vlido ]
Esta especificacin no restringe la semntica, la utilizacin, o (ms all de la sintaxis) los nombres de los tipos de
elementos y de los atributos, excepto los nombres que comiencen por (('X'|'x')('M'|'m')('L'|'l')) que estn reservados para
estandarizacin en esta o en futuras versiones de esta especificacin.
Restriccin de Buena-Formacin: Igual de Tipo de Elemento
El Nombre en la etiqueta de fin de un elemento debe ser igual al de la etiqueta de comienzo.
Restriccin de Validez: Elemento Vlido
Un elemento es vlido si existe una declaracin que cumpla con la regla elementdecl donde el Nombre sea igual al tipo de
elemento, y uno se mantenga uno de los siguientes:
1. La declaracin cumple la regla EMPTY y el elemento no tiene contenido.
2. La declaracin cumple la regla 'children' y la secuencia 'elementos child' pertenece al lenguaje generado por la
expresin regular en el modelo de contenido, con espacios en blanco opcionales (caracteres que cumplan la
regla S) entre todo par de elementos 'child'.
3. La declaracin cumple la regla 'Mixed' y el contenido de la misma consiste en datos carcter y 'elementos child'
cuyos tipos sean iguales a los nombres del modelo de contenido.
4. La declaracin cumple la regla ANY, y los tipos de cualquier 'elemento child' han sido declarados.

91 de 137

3.1 ETIQUETAS DE COMIENZO, ETIQUETAS DE FIN Y ETIQUETAS DE "ELEMENTOS-VACOS"
El comienzo de todo elemento XML no vaco est marcado por una etiqueta de comienzo.
Etiqueta de Comienzo
[40] STag ::= '<' Name (S Attribute)* S? '>' [ RBF: Espec Atrib nico ]
[41] Attribute ::= Name Eq AttValue [ RV: Tipo de Valor Atributo ]
[ RBF: No Referencia a Entidad Externa ]
[ RBF: No < en Valores Atributo ]
El Nombre en las etiquetas de comienzo y de fin proporciona el tipo del elemento. Los pares Name-AttValue son referidos
como las especificaciones de atributos del elemento, con el Name en cada par referido como el nombre de atributo
y el contenido del AttValue (el texto entre los delimitadores ' o ") como el valor del atributo.
Restriccin de Buena-Formacin: Especificacin de Atributo nico
ningn nombre de atributo puede aparecer ms de una vez en la misma etiqueta de comienzo o de "elemento-vaco".
Restriccin de Validez: Tipo de Valor de los Atributos
El atributo debe haber sido declarado, el valor debe ser del tipo declarado para l. (Para tipos de atributos, ver
"3.3 Declaraciones de Listas de Atributos").
Restriccin de Buena-Formacin: No Referencia a Entidades Externas
Los valores de los atributos no pueden contener entidades referencia directas o indirectas a entidades externas.
Restriccin de Validez: No < en Valores de Atributos
El texto de reemplazo de cualquier entidad referenciada directa o indirectamente en un valor de atributo (cualquiera
salvo "<") no debe contener el carcter <.
Un ejemplo de etiqueta de comienzo podra ser:
<defterm id="dt-perro" term="perro">
El final de todo elemento que comience con una etiqueta de comienzo debe ser marcado con una etiqueta de fin que
contenga un nombre que responda al tipo de elemento dado en la etiqueta de comienzo:
Etiqueta de Fin
[42] ETag ::= '</' Name S? '>'
Un ejemplo de etiqueta de fin:
</defterm>
El texto entre las etiquetas de comienzo y de fin se denomina contenido:
Contenido de los Elementos
[43] content ::= (element | CharData | Reference | CDSect | PI | Comment)*
Si un elemento est vaco, debe ser representado por una etiqueta de comienzo seguida de una etiqueta de fin, o por
una etiqueta de "elemento-vaco". Una etiqueta de "elemento-vaco" tiene la siguiente forma:
Etiquetas para Elementos Vacos
[44] EmptyElemTag ::= '<' Name (S Attribute)* S? '/>' [ RBF: nico Atrib. Especif. ]
Las etiquetas de "elemento-vaco" pueden ser utilizadas por cualquier elemento que no tenga contenido, sea o no
declarado mediante la utilizacin de la palabra clave EMPTY. Por interoperatividad, la etiqueta de "elemento-vaco" debe
ser utilizada, y slo puede ser utilizada, en elementos que estn declarados como EMPTY.
Ejemplos de "elementos-vacos":
<IMG align="left"

92 de 137

src="http://www.w3.org/Icons/WWW/w3c_home" />
<br></br>
<br/>

3.2 DECLARACIONES DE TIPO DE ELEMENTO
La estructura elemento de un documento XML puede, a efectos de validacin, estar restringida mediante la utilizacin de
declaraciones de tipos de elementos y de listas de atributos. Una declaracin de tipo de elemento restringe el contenido
del propio elemento.
Las declaraciones de tipo de elemento suelen restringir el tipo de elementos que pueden aparecer como 'children' del
citado elemento. Un procesador XML puede indicar una advertencia cuando una declaracin menciona un tipo de
elemento para el que no se ha dado una declaracin, como opcin del usuario, dado que esto no supone ser un error.
Una declaracin de tipo de elemento es de la forma:
Declaracin de Tipo de Elemento
[45] elementdecl ::= '<!ELEMENT' S Name S contentspec S? '>' [ RV: Declaracin de Tipo de Elemento nico ]
[46] contentspec ::= 'EMPTY' | 'ANY' | Mixed | children
donde la produccin Name proporciona el tipo de elemento que se est declarando.
Restriccin de Validez: Declaracin nica de Tipo de Elemento
Ningn tipo de elemento debe ser declarado ms de una vez.
Ejemplos de declaraciones de tipo de elemento:
<!ELEMENT br EMPTY>
<!ELEMENT p (#PCDATA|emph)* >
<!ELEMENT %name.para; %content.para; >
<!ELEMENT contenedor ANY>

3.2.1 CONTENIDO DEL ELEMENTO
Un tipo de elemento tiene contenido del elemento cuando los elementos de ese tipo deben contener slo elementos
hijos (no datos carcter), opcionalmente separados por "espacios en blanco" (caracteres que cumplan la regla S). En este
caso, la restriccin incluye un modelo de contenido, una gramtica simple que gobierna los tipos de 'elementos hijo'
permitidos y el orden en que pueden aparecer. La gramtica est constituida por partculas de contenido (cps), que
consisten en nombres, 'listas de seleccin' de partculas de contenido o 'listas secuencia' de partculas de contenido:
Modelos de Contenido de Elemento
[47] children ::= (choice | seq) ('?' | '*' | '+')?
[48] cp ::= (Name | choice | seq) ('?' | '*'
| '+')?
[49] choice ::= '(' S? cp ( S? '|' S? cp )* S? ')' [ RV: Grupo Apropiado/Anidamiento de PEs ]
[50] seq ::= '(' S? cp ( S? ',' S? cp )* S? ')' [ RV: Grupo Apropiado/Anidamiento de PEs ]
donde cada 'Name' es el tipo de un elemento que puede aparecer como un 'child'. Cualquier partcula de contenido en
una lista de seleccin puede aparecer en el contenido del elemento donde la lista de seleccin aparece en la gramtica.
Las partculas de contenido que aparecen en las listas de secuencias deben aparecer cada una en el contenido del
elemento en el orden dado en la lista. El carcter opcional que sigue a un nombre o una lista gobierna si el elemento o
las partculas de contenido en la lista pueden aparecer una o ms veces (+), cero o ms (*), o cero o una vez (?). La
ausencia de dicho operador significa que el elemento o partcula de contenido debe aparecer exactamente una vez. Esta
sintaxis y su significado son idnticos a los utilizados en las reglas de produccin de esta especificacin.
El contenido de una elemento es igual al modelo de contenido si y slo si es posible trazar una ruta a travs del modelo
de contenido, obedeciendo la secuencia, opcin y operadores de repeticin e igualando cada elemento en el contenido
contra un tipo de elemento en el modelo de contenido. Por compatibilidad, se produce un error si un elemento del

93 de 137

documento puede ser igual a ms de una ocurrencia de un tipo de elemento en el modelo de contenido. Para ms
informacin, ver "E. Modelos de Contenido Deterministas".
Restriccin de Validez: Grupo apropiado/Anidamiento de PEs
Las entidades parmetro texto de reemplazo deben ser anidadas apropiadamente con grupos de parntesis. Es decir, si
cualquiera de los parntesis de apertura o de cierre de una construccin choice, seq o Mixed est contenida en el texto de
reemplazo para una entidad parmetro, ambas deben estar contenidas en el mismo texto de reemplazo. Por
interoperatividad, si una entidad parmetro aparece en una construccin choice, seq o Mixed, su texto de reemplazo no
tendra que estar vaco, y ni el primero ni el ltimo carcter 'no-blanco' del texto de reemplazo debe ser un 'conector'. (|
o ,).
Ejemplos de modelos de contenido de elemento:
<!ELEMENT especif (frente, cuerpo, epilogo?)>
<!ELEMENT div1 (cabecera, (p | lista | nota)*, div2*)>
<!ELEMENT cuerpo-diccionario (%div.mix; | %dict.mix;)*>

3.2.2 "CONTENIDO MEZCLADO"
Un tipo de elemento tiene "contenido mezclado" cuando los elementos de ese tipo pueden contener datos carcter,
opcionalmente entremezclados con elementos child. En este caso, los tipos de los elementos 'child' pueden ser
restringidos, pero no su orden o su nmero de apariciones:
Declaracin de "Contenido Mezclado"
[51] Mixed ::= '(' S? '#PCDATA' (S? '|' S? Name)* S? ')*'
| '(' S? '#PCDATA' S? ')' [ RV: Grupo Apropiado/Anidam. PEs ]
[ RV: No Tipos Duplicados ]
donde las construcciones Name dan los tipos de los elementos que pueden aparecer como hijos.
Restriccin de Validez: No Duplicacin de Tipos
El mismo nombre no debe aparecer ms de una vez en una sola declaracin de "contenido mezclado".
Ejemplos de declaraciones de contenido mezclado:
<!ELEMENT p (#PCDATA|a|ul|b|i|em)*>
<!ELEMENT p (#PCDATA | %font; | %phrase; | %special; | %form;)* >
<!ELEMENT b (#PCDATA)>

3.3 DECLARACIONES DE LISTAS DE ATRIBUTOS
Los atributos se utilizan para asociar pares nombre-valor con elementos. Las especificaciones de atributos pueden
aparecer slo dentro de las etiquetas de comienzo y en las etiquetas de elemento vaco. Las reglas de produccin
utilizadas para reconocer su aparicin en "3.1 Etiquetas de Comienzo, Etiquetas de Fin y Etiquetas de Elementos-Vacos".
Las declaraciones de Listas de Atributos pueden utilizarse para:
Definir el conjunto de atributos pertenecientes a un tipo de elemento dado.
Establecer restricciones de tipo para dichos atributos.
Proporcionar valores por defecto para los atributos.
Las declaraciones de Listas de Atributos especifican el nombre, tipo de datos y valores por defecto (si tuvieran) para
cada atributo asociado con un tipo de elemento dado:
Declaraciones de Listas de Atributos
[52] AttlistDecl ::= '<!ATTLIST' S Name AttDef* S? '>'
[53] AttDef ::= S Name S AttType S DefaultDecl

94 de 137

La expresin Name en la regla AttlistDecl es tipo del elemento. Como opcin de usuario, los procesadores XML pueden
indicar si los atributos estn declarados para un tipo de elemento que no est declarado, hecho que no constituye un
error. La expresin Name en la regla AttDef es el nombre del atributo.
Cuando se proporciona ms de una AttlistDecl para un tipo de elemento dado, los contenidos de todos esas declaraciones
se entremezclan. Cuando se proporciona ms de una definicin para el mismo atributo de un tipo de elemento dado, se
mantiene la primera declaracin y se ignora el resto. Por interoperatividad, los creadores de DTDs deben proporcionar, al
menos, una declaracin de lista de atributos para un tipo de elemento dado, una definicin de atributo para un nombre
de atributo dado, y por lo menos una definicin de atributo en cada declaracin de lista de atributos Por
interoperatividad, los procesadores XML pueden indicar una alerta cuando se proporciona ms de una declaracin de lista
de atributos para un tipo de elemento dado, o ms de una definicin de atributo para una atributo dado. Esta es una
opcin de usuario y no supone ningn tipo de error.

3.3.1 TIPOS DE ATRIBUTOS
Los tipos de atributos de XML son de tres tipos: el tipo cadena, el conjunto de los tipos 'tokenizados' y los tipos
enumerados. El tipo cadena puede tomar cualquier cadena literal como valor. Los tipos 'tokenizados' poseen restricciones
lxicas y semnticas variantes, como se describe a continuacin:
Tipos de Atributos
[54] AttType ::= StringType | TokenizedType
| EnumeratedType
[55] StringType ::= 'CDATA'
[56] TokenizedType ::= 'ID' [ RV: ID ]
[ RV: Un ID por Tipo de Elemento ]
[ RV: Atributo por Defecto ID ]
| 'IDREF' [ RV: IDREF ]
| 'IDREFS' [ RV: IDREF ]
| 'ENTITY' [ RV: Nombre de Entidad ]
| 'ENTITIES' [ RV: Nombre de Entidad ]
| 'NMTOKEN' [ RV: Nombre de Token ]
| 'NMTOKENS' [ RV: Nombre de Token ]
Restriccin de Validez: ID
Los valores de tipo ID deben ser iguales a la regla de produccin Name. Un nombre no puede aparecer ms de una vez
de un documento XML como valor de este tipo. P.e.: los valores de ID slo deben identificar a los elementos que los
producen.
Restriccin de Validez: Un ID por Tipo de Elemento
Ningn tipo de elemento puede tener ms de un atributo ID especificado.
Restriccin de Validez: Atributo por Defecto ID
Un atributo ID debe tener declarado por defecto el valor #IMPLIED o #REQUIRED.
Restriccin de Validez: IDREF
Los valores del tipo IDREF deben ser iguales a la regla de produccin Name, y los valores del tipo IDREFS deben ser
iguales a Names. Cada Name debe ser igual al valor de un atributo ID de alguno de los elementos del documento XML.
P.e. los valores de IDREF deben ser iguales a los valores de algn atributo ID.
Restriccin de Validez: Nombre de Entidad
Los valores del tipo ENTITY deben ser iguales a la regla de produccin Name, los valores del tipo ENTITIES deben ser
iguales a Names. Cada Name debe ser igual al nombre de una entidad no analizada declarada en la DTD.
Restriccin de Validez: Nombre de Token
Los valores del tipo NMTOKEN deben ser iguales a la regla de produccin Nmtoken, los valores del tipo NMTOKENS deben
ser iguales a Nmtokens.
Los atributos enumerados pueden tomar una de las listas de valores proporcionadas en la declaracin. Existen dos
tipos de tipos enumerados:
Tipos de Atributos Enumerados

95 de 137

[57] EnumeratedType ::= NotationType | Enumeration
[58] NotationType ::= 'NOTATION' S '(' S? Name (S? '|' S? Name)* S? ')' [ RV: Atributos de Notacin ]
[59] Enumeration ::= '(' S? Nmtoken (S? '|' S? Nmtoken)* S? ')' [ RV: Enumeracin ]
Un atributo NOTATION identifica una notacin, declarada en la DTD con su sistema asociado y/o identificadores pblicos,
para ser utilizados en la interpretacin del elemento al cual est unido el atributo.
Restriccin de Validez: Atributos de Notacin
Los valores de este tipo deben ser iguales a los del nombre de notacin incluidos en la declaracin. Todos los nombres de
notacin de la declaracin deben ser declarados.
Restriccin de Validez: Enumeracin
Los valores de este tipo deben ser iguales a los de los tokens Nmtoken de la declaracin.
Por interoperatividad, no puede aparecer el mismo Nmtoken ms de una vez en los tipos de atributos enumerados de un
nico tipo de elemento.

3.3.2 ATRIBUTOS POR DEFECTO
Una declaracin de atributos proporciona informacin sobre si la presencia de los atributos es requerida, o sino, como
debe reaccionar un procesador XML si un atributo declarado est ausente en un documento.
Atributos por Defecto
[60] DefaultDecl ::= '#REQUIRED' | '#IMPLIED'
| (('#FIXED' S)? AttValue) [ RV: Atributo Requerido ]
[ RV: Atributo por Defecto Legal ]
[ RBF: No < en Valores de Atributos ]
[ RV: Atributo por Defecto Fijado ]
En una declaracin de atributo, #REQUIRED significa que ese atributo debe ser dado siempre, #IMPLIED que no se da un
valor por defecto. Si la declaracin no es ni #REQUIRED ni #IMPLIED, entonces el valor AttValue contiene el valor por
defecto declarado. La palabra clave #FIXED indica que el atributo debe siempre tener el valor por defecto. Si se declara
el valor por defecto, cuando un procesador XML encuentra un atributo omitido, debe comportarse como si el atributo
estuviese presente, con el valor por defecto declarado.
Restriccin de Validez: Atributo Requerido
Si la declaracin por defecto es la palabra clave #REQUIRED, el atributo debe ser especificado para todos los elementos
del tipo de la declaracin de la lista de atributos.
Restriccin de Validez: Atributo por Defecto Legal
El valor por defecto declarado debe cumplir las restricciones lxicas del tipo de atributo declarado.
Restriccin de Validez: Atributo por Defecto Fijado
Si un atributo tiene un valor por defecto declarado con la palabra clave #FIXED, las instancias de ese atributo deben ser
iguales al valor por defecto.
Ejemplos de declaraciones de listas de atributos:
<!ATTLIST defterm
id ID #REQUIRED
nombre CDATA #IMPLIED>
<!ATTLIST lista
tipo (ordenada|glosario) "ordenada">
<!ATTLIST formulario
metodo CDATA #FIXED "POST">

3.3.3 NORMALIZACIN DE ATRIBUTOS-VALOR
Antes de que el valor de un atributo se pase a la aplicacin o se compruebe su validez, el procesador XML debe
normalizarlo como se indica a continuacin:

96 de 137

una referencia a carcter es procesada mediante la adicin del carcter referenciado al valor del atributo
una referencia a entidad es procesada por procesamiento recursivo del texto de reemplazo de la entidad
un carcter "espacio en blanco" (#x20, #xD, #xA, #x9) es procesado mediante la adicin del valor normalizado
#x20, excepto en la secuencia "#xD#xA" que slo se aade un nico #x20, que es parte de una entidad externa
analizada o el valor literal de entidad de una entidad interna analizada
el resto de caracteres son procesados mediante la adicin del valor normalizado
Si el valor declarado no es de tipo CDATA, el procesador XML debe procesar el valor de atributo normalizado, mediante el
descartado de cualquier carcter espacio (#x20) por delante o por detrs, y mediante el reemplazo de secuencias de
caracteres espacio (#x20) por un nico carcter espacio (#x20).
Todos los atributos para los que no se ha ledo la declaracin deben ser tratado por un analizador no validador como se
declara en CDATA.

3.4 SECCIONES CONDICIONALES
Las secciones condicionales son porciones del subconjunto externo de la declaracin de tipo de documento que estn
incluidas en, o excluidas de, la estructura lgica de la DTD basada en la palabra clave que las gobierna.
Seccin Condicionales
[61] conditionalSect ::= includeSect | ignoreSect
[62] includeSect ::= '<![' S? 'INCLUDE' S? '[' extSubsetDecl ']]>'
[63] ignoreSect ::= '<![' S? 'IGNORE' S? '[' ignoreSectContents* ']]>'
[64] ignoreSectContents ::= Ignore ('<![' ignoreSectContents ']]>' Ignore)*
[65] Ignore ::= Char* - (Char* ('<![' | ']]>') Char*)
Como ocurre con los subconjuntos de la DTD internos y externos, una seccin condicional puede contener una o ms
declaraciones completas, comentarios, instrucciones de procesamiento o secciones condicionales anidadas,
entremezcladas con espacios en blanco.
Si la palabra clave de la seccin condicional es INCLUDE, los contenidos de la seccin condicional son parte de la DTD. Si
la palabra clave es por el contrario IGNORE, los contenidos de la seccin condicional no son parte lgica de la DTD. Hay
que subrayar que para poder realizar un anlisis con confianza, incluso los contenidos de la secciones condicionales
ignoradas debe ser ledo para poder detectar secciones condicionales anidadas y asegurar que el final de la seccin
ignorada ms extrema se detecta de manera adecuada. Si una seccin condicional con la palabra clave INCLUDE aparece
dentro de una seccin condicional ms grande con la palabra clave IGNORE, ambas, la ms exterior y la interior son
ignoradas.
Si la palabra clave de la seccin condicional es una referencia a entidad parmetro, la entidad parmetro debe ser
reemplazada por su contenido antes de que el procesador decida si incluye o ignora la seccin condicional.
Un ejemplo:
<!ENTITY % borrador 'INCLUDE' >
<!ENTITY % final 'IGNORE' >

<![%borrador;[
<!ELEMENT libro (comentarios*, titulo, cuerpo, suplementos?)>
]]>
<![%final;[
<!ELEMENT libro (titulo, cuerpo, suplementos?)>
]]>

4. ESTRUCTURAS FSICAS
Un documento XML puede consistir de una o ms unidades de almacenamiento. Estas se denominan entidades, y todas
ellas poseen contenidos y todas son (excepto la entidad documento, ver ms abajo, y el subconjunto externo de la

97 de 137

DTD) identificadas por su nombre. Cada documento XML posee una entidad denominada entidad documento, la cual
sirve de punto de comienzo al procesador XML y que puede contener a todo el documento.
Las entidades pueden ser analizadas o no analizadas. Los contenidos de una entidad analizada son referenciados como
su texto de reemplazo. Este texto es considerado parte integral del documento.
Una entidad no analizada es un recurso cuyo contenido puede o no ser texto, y si lo es, puede que no sea XML. Cada
entidad no analizada tiene notacin asociada, identificada por su nombre. A parte de la necesidad de que los
procesadores XML hagan accesibles los identificadores de la entidad y la notacin a la aplicacin, XML no impone ningn
otro tipo de restricciones a los contenidos de las entidades no analizadas.
Las entidades analizadas son invocadas por su nombre mediante la utilizacin de referencias a entidades, las no
analizadas lo hacen por su nombre, dado en el valor de los atributos ENTITY o ENTITIES.
Las Entidades Generales son entidades que se utilizan dentro del contenido del documento. En esta especificacin, las
entidades generales son referenciadas, a veces, simplemente con el trmino entidad, siempre y cuando no se produzcan
ambigedades. Las entidades parmetro son entidades analizadas que se utilizan en las DTDs. Estos dos tipos de
entidades utilizan diferentes formas y referencias y son reconocidas en contextos diferentes, es ms, ocupan diferentes
espacios de nombres. Pueden existir una entidad parmetro y una entidad general con el mismo nombre, dado que son
entidades diferentes.

4.1 REFERENCIAS A CARACTERES Y ENTIDADES
Una referencia a carcter hace referencia a un carcter especifico del conjunto de caracteres de la norma ISO/IEC
10646. Un ejemplo puede ser un carcter no accesible directamente a travs de los dispositivos de introduccin de datos.
Referencia a Carcter
[66] CharRef ::= '&#' [0-9]+ ';'
| '&#x' [0-9a-fA-F]+ ';' [ RBF: Carcter Legal ]
Restriccin de Buena-Formacin: Carcter Legal
Los caracteres referenciados mediante la utilizacin de referencias a caracteres deben cumplir los requisitos de la regla
de produccin Char.
Si la referencia a carcter comienza por "&#x", los dgitos y las letras que le siguen hasta la aparicin de ; proporcionan
una representacin hexadecimal del punto cdigo del carcter en la norma ISO/IEC 10646. Si comienza por "&#", los
dgitos que aparecen hasta la aparicin de ; indican una representacin decimal del punto cdigo de carcter.
Una referencia a entidad referencia al contenido de una entidad con nombre. Las referencias a entidades generales
analizadas utilizan el carcter ampersand (&) y, el punto y coma (;) como delimitadores. Las referencias a entidades
parmetro utilizan el signo de porcentaje (%) y el punto y coma (;) como delimitadores.
Referencia a Entidad
[67] Reference ::= EntityRef
| CharRef
[68] EntityRef ::= '&' Name ';' [ RBF: Entidad Declarada ]
[ RV: Entidad Declarada ]
[ RBF: Entidad Analizada ]
[ RBF: No Recursin ]
[69] PEReference ::= '%' Name ';' [ RV: Entidad Declarada ]
[ RBF: No Recursin ]
[ RBF: En DTD ]
Restriccin de Buena-Formacin: Entidad Declarada
En los documentos sin ningn DTD, un documento con slo un subconjunto de DTD interno que no contiene referencias a
entidades parmetro, o un documento con la clusula "standalone='yes'", el smbolo Name dado en la referencia a
entidad debe ser igual al dado en una declaracin de entidad/A>, excepto en los documentos bien-formados que utilicen
las entidades predeclaradas: amp, lt, gt, apos, quot. La declaracin de las entidades parmetro deben preceder a
cualquier referencia a ellas. De igual manera, las declaracin de las entidades generales debe preceder a cualquier
referencia a ellas que aparezca en la declaracin de los valores por defecto de una lista de atributos. Si las entidades se
declaran en el subconjunto externo o en las entidades parmetro externas, los procesadores no validadores no estn
obligados a leer y procesar sus declaraciones. Para esos documentos, la regla que dice que una entidad debe ser
declarada es una restriccin de buena-formacin slo si se da lo siguiente: standalone='yes'.

98 de 137

Restriccin de Validez: Entidad Declarada
En los documentos con un subconjunto externo o entidades parmetro externas con la expresin "standalone='no'", el
Name dado en la referencia a entidad debe ser igual al dado en una declaracin de entidad. Por interoperatividad, los
documentos vlidos deberan declarar las entidades amp, lt, gt, apos, quot, de la manera especificada en la seccin
"4.6 Entidades Predefinidas". La declaracin de una entidad parmetro debe preceder a cualquier referencia a ella. De
manera similar, la declaracin de una entidad general debe preceder a cualquier referencia a ella que aparezca en la
declaracin de los valores por defecto de una lista de atributos.
Restriccin de Buena-Formacin: Entidad Analizada
Una referencia a entidad no debe contener el nombre de una entidad no analizada. Las entidades no analizadas slo
pueden ser referenciadas en valores de atributos declarados para ser del tipo ENTITY o ENTITIES.
Restriccin de Buena-Formacin: No Recursin
Una entidad analizada no debe contener una referencia recursiva a s misma, ni directa ni indirectamente.
Buena-Formacin Restriccin: En DTD
Las referencias a entidades parmetro slo pueden aparecer en la DTD.
Ejemplos de referencias a caracteres y entidades:
Pulse <tecla>menor</tecla> (<) para guardar las opciones.
Este documento fue creado el &fechadoc; y
su clasificacin &nivel-seguridad;.
Ejemplos de referencias a entidades parmetro:

<!ENTITY % ISOLat2
SYSTEM "http://www.xml.com/iso/isolat2-xml.entities" >

%ISOLat2;

4.2 DECLARACIONES DE ENTIDAD
Las entidades son declaradas de este modo:
Declaracin de Entidades
[70] EntityDecl ::= GEDecl | PEDecl
[71] GEDecl ::= '<!ENTITY' S Name S EntityDef S? '>'
[72] PEDecl ::= '<!ENTITY' S '%' S Name S PEDef S? '>'
[73] EntityDef ::= EntityValue | (ExternalID NDataDecl?)
[74] PEDef ::= EntityValue | ExternalID
El smbolo Name identifica la entidad en una referencia a entidad o, en el caso de una entidad no analizada, en el valor
de los atributos ENTITY o ENTITIES. Si se declara la misma entidad ms de una vez, se le vincula la primera declaracin
encontrada. Como opcin de usuario, los procesadores XML pueden indicar si las entidades pueden ser declaradas
mltiples veces.

4.2.1 ENTIDADES INTERNAS
Si la definicin de entidad es un EntityValue, la entidad definida se denomina entidad interna. No existe ningn objeto
fsico de almacenamiento separado, y el contenido de la entidad se da en la declaracin. Algunos procesados de
entidades y referencias a caracteres en el valor de la entidad literal pueden ser requeridos para producir el texto de
reemplazo correcto: vase "4.5 Construccin de Texto de Reemplazo de Entidad Interna".
Una entidad interna es una entidad analizada.
Un ejemplo de una declaracin de entidad interna:
<!ENTITY Estado-Pub "Esta es una pre-edicin de la
Especificacin.">

99 de 137

4.2.2 ENTIDADES EXTERNAS
Si la entidad no es interna, es una entidad externa, declarada como sigue:
Declaracin de Entidad Externa
[75] ExternalID ::= 'SYSTEM' S SystemLiteral
| 'PUBLIC' S PubidLiteral S SystemLiteral
[76] NDataDecl ::= S 'NDATA' S Name [ RV: Notacin Declarada ]
Si NDataDecl est presente, sta es una entidad no analizada general, sino, es una entidad analizada.
Restriccin de Validez: Notacin Declarada
El Name debe ser igual al nombre declarado de una notacin.
A SystemLiteral se le denomina identificador de sistema de la entidad. Es un URI que puede ser utilizado para obtener
la entidad. El smbolo de 'sostenido' (#) y el identificador de fragmento frecuentemente utilizados con URIs no son,
formalmente, parte del propio URI. Los procesadores XML podran sealar un error si es dado un identificador de
fragmento como parte de un identificador de sistema. Si no se proporciona otra informacin fuera del mbito de esta
especificacin (e.g. un tipo especial de elemento XML definido por una DTD particular, o una instruccin de
procesamiento definida por la especificacin de una aplicacin particular), los URIs relativos son relativos a la localizacin
del recurso dentro del que ocurre la declaracin de entidad. Un URI podra ser relativo a la entidad documento, a la
entidad que contenga el subconjunto de DTD externa, o a alguna otra entidad parmetro externa.
Los procesadores XML deberan manejar los caracteres no ASCII en un URI mediante la representacin del carcter en
UTF-8 como uno o ms de bytes, y despus 'escapar' estos bytes con el 'mecanismo de escapado' de los URIs (e.g.,
convirtiendo cada byte a %HH, donde HH es la notacin hexadecimal del valor del byte).
Adicionalmente al identificador de sistema, un identificador externo puede incluir un identificador pblico. Los
procesadores XML que traten de obtener el contenido de la entidad pueden utilizar el identificador pblico para intentar
generar un URI alternativo. Si el procesador no es capaz de hacer esto, debe utilizar el URI especificado en el literal de
sistema. Antes de aceptar una igualdad, todas las cadenas de espacios en blanco del identificador pblico deben ser
normalizadas a caracteres espacio nicos (#x20), y deben eliminarse los espacios en blanco del comienzo y del final.
Un ejemplo de declaracin de entidad externa:
<!ENTITY abrir-trampa
SYSTEM "http://www.textuality.com/boilerplate/AbrirTrampa.xml">
<!ENTITY abrir-trampa
PUBLIC "-//Textuality//TEXT Standard abrir-trampa boilerplate//EN"
"http://www.textuality.com/boilerplate/AbrirTrampa.xml">
<!ENTITY img-trampa
SYSTEM "../grafix/AbrirTrampa.gif"
NDATA gif >

4.3 ENTIDADES ANALIZADAS
4.3.1 DECLARACIN DE TEXTO
Las entidades analizadas externas pueden empezar, cada una de ellas, con una declaracin de texto.
Declaracin de Texto
[77] TextDecl ::= '<?xml' VersionInfo? EncodingDecl S? '?>'
La declaracin de texto debe ser proporcionada literalmente, no por referencia a una entidad analizada. Ninguna
declaracin de texto puede aparecer en cualquier posicin que no sea el comienzo de una entidad analizada externa.

4.3.2 ENTIDADES ANALIZADAS BIEN-FORMADAS

100 de 137

La entidad documento est bien-formada si cumple la produccin denominada document. Una entidad analizada general
externa est bien-formada si cumple la produccin denominada extParsedEnt. Una entidad parmetro externa est bien-
formada si cumple la produccin denominada extPE.
Entidad Analizada Externa Bien-Formada
[78] extParsedEnt ::= TextDecl? content
[79] extPE ::= TextDecl? extSubsetDecl
Una entidad analizada general interna est bien-formada si su texto de reemplazo cumple la produccin denominada
content. Todas las entidades parmetro internas estn bien-formadas por definicin.
Una consecuencia de la buena-formacin en entidades es que las estructuras lgica y fsica en los documentos XML estn
anidadas apropiadamente. Ninguna etiqueta de comienzo, etiqueta de fin, etiqueta de elemento vaco, elemento,
comentario, instruccin de procesamiento, referencia a carcter o referencia a entidad puede comenzar en una entidad y
terminar en otra.

4.3.3 CODIFICACIN DE CARACTERES EN ENTIDADES
Cada entidad analizada externa en un documento XML puede utilizar una codificacin diferente para sus caracteres.
Todos los procesadores XML deben ser capaces de leer entidades tanto UTF-8 como en UTF-16.
Las entidades codificadas en UTF-16 deben comenzar con la 'Byte Order Mark' descrita por la norma ISO/IEC 10646
Anexo E y Apndice B de Unicode (el carcter 'ZERO WIDTH NO-BREAK SPACE', #xFEFF). Esta es una seal de
codificacin, no parte de la marcacin o de los datos carcter del documento XML. Los procesadores XML deben ser
capaces de utilizar este carcter para diferenciar entre documentos codificados en UTF-8 o en UTF-16.
Aunque slo se requiere que los procesadores XML lean entidades en las codificaciones UTF-8 y UTF-16, se reconoce que
se utilizan otras codificaciones en el mundo, y puede ser deseable que un procesador XML pueda leer entidades que las
utilicen. Las entidades analizadas que se almacenan en una codificacin que no sea UTF-8 o UTF-16 deben comenzar con
una declaracin de texto que contenga una declaracin de codificacin:
Declaracin de Codificacin
[80] EncodingDecl ::= S 'encoding' Eq ('"' EncName '"' | "'"
EncName "'" )
[81] EncName ::= [A-Za-z] ([A-Za-z0-9._] | '-')* /* El nombre de la codificacin slo contiene
caracteres latinos */
en la entidad documento, la declaracin de codificacin es parte de la declaracin XML. La regla EncName es el nombre
de la codificacin utilizada.
En las declaraciones de codificacin, los valores "UTF-8", "UTF-16", "ISO-10646-UCS-2" y "ISO-10646-UCS-4" deben ser
utilizados para las diferentes codificaciones y transformaciones de Unicode / ISO/IEC 10646, los valores "ISO-8859-1",
"ISO-8859-2", ... "ISO-8859-9" deben ser utilizados para las partes de la ISO 8859, y los valores "ISO-2022-JP",
"Shift_JIS" y "EUC-JP" deben ser utilizados para las diferentes formas de codificacin de JIS X-0208-1997. Los
procesadores XML deberan reconocer otras codificaciones, se recomienda que sean las codificaciones de caracteres
registradas (como charsets) por la Internet Assigned Numbers Authority [IANA], otras codificaciones slo sern
referenciadas mediante la utilizacin de sus nombres registrados. Estos nombres registrados estn definidos para no ser
sensibles al tipo, por lo que los procesadores que quieran contemplarlos debern tratarlos de ese modo.
En la ausencia de informacin proporcionada por un protocolo de transporte externo (e.g. HTTP o MIME), es un error que
una entidad incluya una declaracin de codificacin para ser presentada al procesador XML en una codificacin diferente a
la nombrada en la declaracin, que una declaracin de codificacin aparezca en un lugar que no sea el comienzo de una
entidad externa, o que una entidad que no comience una 'Byte Order Mark' o una declaracin de codificacin utilice una
codificacin que no sea UTF-8. Dado que ASCII es un subconjunto de UTF-8, no es estrictamente necesaria una
declaracin de codificacin para las entidades ordinarias ASCII.
Se produce un error fatal si un procesador XML encuentra una entidad con una codificacin que es incapaz de procesar.
Ejemplos de declaraciones de codificacin:
<?xml encoding='UTF-8'?>
<?xml encoding='EUC-JP'?>

101 de 137

4.4 TRATAMIENTO DE ENTIDADES Y REFERENCIAS POR EL PROCESADOR XML
La tabla de abajo resume el contexto en el que pueden aparecer las referencias a caracteres, las referencias a entidades
y las invocaciones de entidades no analizadas y el comportamiento requerido de los procesadores XML en cada caso. Las
etiquetas de la columna de la izquierda describen el contexto de reconocimiento:
Referencia en Contenido
como una referencia en cualquier lugar despus de la etiqueta de comienzo y antes de la etiqueta de fin de un
elemento, corresponde al no-terminal content.
Referencia en Valor de Atributo
como una referencia dentro del valor de un atributo en una etiqueta de comienzo, o un valor por defecto en una
declaracin de atributo; corresponde al no-terminal AttValue.
Aparece como Valor de Atributo
como un Name, no una referencia, apareciendo tanto como el valor de un atributo que haya sido declarado con
tipo ENTITY, o como uno de los 'tokens' separados por espacios en el valor de un atributo que ha sido declarado
con tipo ENTITIES.
Referencia en Valor de Entidad
como una referencia dentro del valor literal de una entidad parmetro o una entidad interna en la declaracin de
la entidad; corresponde al no-terminal EntityValue.
Referencia en DTD
como una referencia dentro de los subconjuntos interno o externo de la DTD, pero fuera de EntityValue o de
AttValue.
Tipo Entidad

Parmetro
Interna
General
Externa Analizada
General No Analizada
Carcter
Referencia
en Contenido
No reconocida Incluida Incluida si validada Prohibida Incluida
Referencia en
Valor de Atributo
No reconocida Incluida en literal Prohibida Prohibida Incluida
Aparece como
Valor de Atributo
No reconocida Prohibida Prohibida Notificar No reconocida
Referencia
en EntityValue
Incluida en literal Obviada Obviada Prohibida Incluida
Referencia
en DTD
Incluida como PE Prohibida Prohibida Prohibida Prohibida
4.4.1 NO RECONOCIDAS
Fuera de la DTD, el carcter % no tiene un significado especial; de este modo, lo que sera una referencia a una entidad
parmetro en una DTD no es reconocido como marcacin en el contenido. De igual manera, los nombres de las entidades
no analizadas no son reconocidos excepto cuando aparecen en el valor de un atributo declarado apropiadamente.

4.4.2 INCLUIDAS
Una entidad es incluida cuando su texto de reemplazo es obtenido y procesado, en lugar de la propia referencia, como si
fuese parte del documento en el lugar donde fue reconocida la referencia. El texto de reemplazo puede contener datos
carcter y marcaciones (excepto para entidades parmetro), que deben ser reconocidos de la forma habitual, a no ser
que el texto de reemplazo de las entidades utilizado para 'escapar' delimitadores de marcacin (las entidades amp, lt, gt,
apos, quot) siempre se tratan como datos. (La cadena "AT&T;" se expande como "AT&T;" y el 'ampersand' restante
no es reconocido como un delimitador de referencia-entidad). Una referencia a carcter es incluida cuando el carcter
indicado es procesado en lugar de la referencia propiamente dicha.

4.4.3 INCLUIDAS SI VALIDADAS
Cuando un procesador XML reconoce una referencia a una entidad analizada, en vez de validar el documento, el
procesador debe incluir su texto de reemplazo. Si la entidad es externa y el procesador no intenta validar el documento

102 de 137

XML, el procesador puede, pero no necesita, incluir el texto de reemplazo de la entidad. Si un analizador no validador no
incluye el texto de reemplazo, debe informar a la aplicacin que reconoci, pero que no ley, la entidad.
Esta regla se basa en el reconocimiento que la inclusin automtica proporcionada por SGML y el mecanismo de entidad
XML, principalmente diseada para soportar la modularidad en la creacin. No es necesariamente apropiada para otras
aplicaciones, en particular para visualizacin de documentos. Los visualizadores, por ejemplo, cuando encuentran una
referencia a entidad externa analizada, pueden elegir entre proporcionar una indicacin visual de la presencia de la
entidad y obtenerla para su visualizacin bajo demanda.

4.4.4 PROHIBIDAS
Los siguientes estn prohibidos y constituyen errores fatales:
la apariencia de una referencia a una entidad no analizada.
la apariencia de cualquier carcter o referencia a entidad general en la DTD excepto dentro de un EntityValue o
de un AttValue.
una referencia a una entidad externa en un valor de atributo.

4.4.5 INCLUIDAS EN LITERAL
Cuando una referencia a entidad aparece en un valor de atributo, o una referencia a entidad parmetro aparece en un
valor de entidad literal, su texto de reemplazo es procesado en lugar de la propia referencia, en la que parte documento
donde es reconocida la referencia, excepto el carcter comilla simple o doble en el texto de reemplazo que siempre es
tratado como un dato carcter normal y no terminar el literal. Por ejemplo, esto est bien-formado:
<!ENTITY % SN '"S"' >
<!ENTITY LoQueDijo "El dijo &SN;" >
mientras que esto no lo est:
<!ENTITY FinAtrib "27'" >
<elemento atributo='a-&FinAtrib;>

4.4.6 NOTIFICAR
Cuando el nombre de una entidad no analizada aparece como un 'token' en el valor de un atributo de los tipos declarados
ENTITY o ENTITIES, un procesador validador debe informar a la aplicacin sobre los identificadores de sistema y pblicos
(si hubiese alguno) para ambas entidades y su notacin asociada.

4.4.7 OBVIADAS
Cuando aparece una referencia a entidad general en EntityValue en una declaracin de entidad, es obviado y dejado
como est.

4.4.8 INCLUIDAS COMO PES
Tal como ocurre con las entidades externas analizadas, las entidades parmetro slo necesitan ser incluidas si se valida.
Cuando una referencia a entidad parmetro es reconocida en la DTD e incluida, su texto de reemplazo es alargado
mediante la adicin de carcter de comienzo y un carcter espacio (#x20). La intencin es restringir el texto de
reemplazo a entidades parmetro para contener un nmero integral de 'tokens' gramaticales en la DTD.

4.5 CONSTRUCCIN DE TEXTO DE REEMPLAZO DE ENTIDAD INTERNA

103 de 137

En la discusin del tratamiento de entidades internas, es til distinguir dos formas de valores de entidad. El valor de
entidad literal es la cadena de caracteres entrecomillada actualmente presente en la declaracin de la entidad,
correspondiente al no terminal EntityValue. El texto de reemplazo es el contenido de la entidad, despus del reemplazo
de las referencias a caracteres y a entidades parmetro.
El valor literal de la entidad como se da en una declaracin de entidad interna (EntityValue) puede contener caracteres,
entidades parmetro y referencias a entidades generales. Dichas referencias deben ser contenidas completamente dentro
del valor literal de la entidad. El texto de reemplazo actual que est incluido como se describe arriba debe contener el
texto de reemplazo de cualesquiera entidades parmetro referenciadas, y debe contener el carcter referenciado, en
lugar de cualquier referencia a carcter en el valor literal de la entidad. Sin embargo, las referencias a entidades
generales deben ser dejadas como estn, sin expandir. Por ejemplo, dadas las siguientes declaraciones:
<!ENTITY % editorial "Éditions Gallimard" >
<!ENTITY derechos "Todos los derechos reservados" >
<!ENTITY libro "La Peste: Albert Camus,
© 1947 %editorial;. &derechos;" >
luego el texto de reemplazo para la entidad "libro" es:
La Peste: Albert Camus,
1947 ditions Gallimard. &derechos;
La referencia a entidad general "&derechos;" sera expandida si la referencia "&libro;" apareciera en el contenido del
documento o en el valor de un atributo.
Estas simples reglas pueden crear complejas interacciones. Para una discusin detallada de un ejemplo difcil, vase
"D. Expansin de Referencias a Entidades y Caracteres".

4.6 ENTIDADES PREDEFINIDAS
Las referencias a entidades y a caracteres pueden ser utilizadas para 'escapar' el parntesis angular de apertura, el
ampersand y otros delimitadores. Se especifica un conjunto de entidades generales para (amp, lt, gt, apos, quot) este
propsito. Tambin se pueden utilizar referencias a caracteres numricos, que se expanden inmediatamente cuando son
reconocidas y deben ser tratadas como datos carcter, por lo que las referencias a caracteres numricos "<" y
"&" pueden ser utilizadas para 'escapar' < y & cuando aparecen en los datos carcter.
Todos los procesadores XML deben reconocer estas entidades bien si son declaradas o no. Por interoperatividad, los
documentos XML vlidos deberan declarar estas entidades, como cualesquiera otras, antes de utilizarlas. Si las entidades
en cuestin son declaradas, deben ser declaradas como entidades internas cuyo texto de reemplazo sea nicamente el
carcter 'escapado' o una referencia a carcter a dicho carcter en s, como se muestra abajo.
<!ENTITY lt "<">
<!ENTITY gt ">">
<!ENTITY amp "&">
<!ENTITY apos "'">
<!ENTITY quot """>
Los caracteres < y & en las declaraciones de "lt" y "amp" son 'escapados' doblemente para satisfacer los requerimientos
de la buena-formacin de entidades de reemplazo.

4.7 DECLARACIONES DE NOTACIN
Las notaciones identifican por su nombre el formato de las entidades no analizadas, el formato de los elementos que
dependen de un atributo de notacin, o la aplicacin a la que instruccin de procesamiento est destinada.
Las declaraciones de notacin proporcionan un nombre para la notacin, para ser utilizado en la entidad, en las
declaraciones de listas de atributos y en las especificaciones de atributos, y un identificador externo para la notacin que
pueda permitir que los procesadores XML o sus aplicaciones clientes localicen aplicaciones auxiliadora capaz de procesar
datos en la notacin dada.
Declaraciones de Notacin
[82] NotationDecl ::= '<!NOTATION' S Name S (ExternalID | PublicID) S? '>'

104 de 137

[83] PublicID ::= 'PUBLIC' S PubidLiteral
los procesadores XML deben proporcionar a las aplicaciones el nombre y el/los identificador/es externos de cualquier
notacin declarada y referenciada en los valores de atributos, definiciones de atributos o declaraciones de entidades.
Adicionalmente pueden convertir los identificadores externos en identificadores de sistema, nombres de archivos u otras
informaciones necesarias para permitir a la aplicacin pedir al procesador los datos en la notacin descrita. (No es un
error, sin embargo, que los documentos XML declaren y referencien a notaciones para las cuales no hay disponibles
aplicaciones de notacin especfica en sistemas donde est ejecutndose el procesador XML o la aplicacin).

4.8 ENTIDAD DOCUMENTO
La entidad documento sirve como raz del rbol de entidades y de punto de comienzo para los procesadores XML. Esta
especificacin no especifica cmo localizar la entidad documento el procesador XML. A diferencia de otras entidades, la
entidad documento no tiene nombre y puede aparecer en la corriente de entrada de un procesador sin ningn tipo de
identificacin.

5. CONFORMANCIA
5.1 PROCESADORES VALIDADORES Y NO VALIDADORES
Los procesadores XML conformantes son de dos clases: validadores y no validadores.
Los procesadores validadores y los no validadores deben informar sobre las violaciones de las restricciones de buena-
formacin de esta especificacin, en el contenido de la entidad documento y cualesquiera otras entidades analizadas que
lean.
Los procesadores validadores deben informar de las violaciones de las restricciones expresadas por las declaraciones
en la DTD, y de fallos para completar las restricciones de validez dadas en esta especificacin. Para llevar a cabo esto, los
procesadores XML validadores deben leer y procesar la DTD completa y todas entidades externas analizadas
referenciadas en el documento.
Los procesadores no validadores slo tienen que leer la entidad documento, incluyendo el subconjunto de DTD interno
completo, para determinar la buena-formacin. Aunque no se requiera la comprobacin de la validez del documento,
stos tienen que procesar todas las declaraciones que lean en el subconjunto de la DTD interna y en cualquier entidad
parmetro que lean, a partir de la primera referencia a entidades parmetro que no lean, es decir, deben utilizar la
informacin en esas declaraciones para normalizar los valores de atributos, incluir el texto de reemplazo de las entidades
internas y proporcionar valores de atributos por defecto. No deben procesar declaraciones de entidades o declaraciones
de listas de atributos encontradas despus de una referencia a una entidad parmetro que no es leda, dado que la
entidad puede contener declaraciones anulantes.

5.2 UTILIZACIN DE PROCESADORES XML
El comportamiento de los procesadores XML validadores es altamente predecible. Deben leer todos los trozos de
documento e informar sobre todas las violaciones de buena-formacin y validez. Se requiere menos para un procesador
no validador, no necesita leer ninguna parte del documento que no sea la entidad documento. Este genera dos efectos
que pueden ser importantes para los usuarios de los procesadores XML:
Ciertos errores de buena-formacin, especficamente esos en los que se requiere leer las entidades externas, no
sern detectados por un procesador no validador. Los ejemplos incluyen las restricciones denominadas Entidad
Declarada, Entidad Analizada y No Recursin, as como algunos de los casos descritos como prohibidos en
"4.4 Tratamiento de Entidades y Referencias por el Procesador XML ".
La informacin pasada del procesador a la aplicacin puede variar, dependiendo de si el procesador lee
entidades parmetro y externas. Por ejemplo, un procesador no validador no puede normalizar valores de
atributos, incluir el texto de reemplazo de las entidades internas, o proporcionar valores de atributos por
defecto, donde hacerlo depende de si se han ledo las declaraciones en entidades externas o en entidades
parmetro.
Para una mxima fiabilidad en la interoperatividad entre los diferentes procesadores, las aplicaciones que utilicen
procesadores no validadores deberan fiarse de los comportamientos no requeridos de esos procesadores. Las
aplicaciones que requieran facilidades como el uso de atributos por defecto o entidades internas que sean declaradas en
entidades externas deberan utilizar procesadores XML validadores.

105 de 137

6. NOTACIN
La gramtica formal de XML se da en esta especificacin utilizando una notacin 'Backus-Naur Extendida' (EBNF) muy
simple. cada regla de la gramtica define un smbolo, de la forma
smbolo ::= expresin
Los smbolos se escriben con una letra mayscula inicial si son definidos por una expresin regular o sino, con una letra
minscula inicial. Las cadenas literales se entrecomillan.
En la expresin de la parte derecha de una regla, las siguientes expresiones se utilizan para contener a cadenas de uno a
ms caracteres:
#xN
donde N es un entero hexadecimal. Esta expresin se refiere a un carcter de la norma ISO/IEC 10646 cuyo
valor cannico (UCS-4), se interpreta como un nmero binario sin signo, con el valor indicado. El nmero de
ceros por la izquierda en la expresin #xN es insignificante. stos son gobernados por el correspondiente valor
de la codificacin utilizada y no son significativos para XML.
[a-zA-Z], [#xN-#xN]
cualquier carcter con una valor en el(los) rango(s) indicado(s) (inclusive).
[^a-z], [^#xN-#xN]
cualquier carcter con un valor fuera del rango indicado.
[^abc], [^#xN#xN#xN]
cualquier carcter con una valor diferente a los caracteres dados.
"cadena"
una cadena literal exactamente igual a la contenida entre las comillas dobles.
'cadena'
una cadena literal exactamente igual a la contenida entre las comillas simples.
Estos smbolos pueden ser combinados para construir patrones ms complejos como sigue. Donde A y B representan
expresiones simples:
(expresin)
la expresin es tratada como una unidad y puede ser combinada como se describe en esta lista.
A?
contiene una A o nada; A opcional.
A B
aparece una A seguida de una B.
A | B
contiene A o B pero no ambas.
A - B
cualquier cadena que contenga A pero que no contenga B.
A+
una o ms apariciones de A.
A*
cero o ms apariciones de A.
Otras notaciones utilizadas en las reglas de produccin son:
/* ... */
comentario.
[ rbf: ... ]
restriccin de buena formacin: identifica una restriccin sobre la buena formacin de documentos asociados
con una regla de produccin.
[ rv: ... ]
restriccin de validez: identifica una restriccin de validez sobre los documentos asociados con una regla de
produccin.

APNDICES
A. REFERENCIAS
A.1 REFERENCIAS NORMATIVAS
IANA
(Internet Assigned Numbers Authority) Official Names for Character Sets, ed. Keld Simonsen et al. Vase
ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets.
IETF RFC 1766
IETF (Internet Engineering Task Force). RFC 1766: Tags for the Identification of Languages, ed. H. Alvestrand.
1995.
ISO 639

106 de 137

(International Organization for Standardization). ISO 639:1988 (E). CODE for the representation of names of
languages. [Geneva]: International Organization for Standardization, 1988.
ISO 3166
(International Organization for Standardization). ISO 3166-1:1997 (E). Codes for the representation of names of
countries and their subdivisions -- Part 1: Country codes [Geneva]: International Organization for
Standardization, 1997.
ISO/IEC 10646
ISO (International Organization for Standardization). ISO/IEC 10646-1993 (E). Information technology --
Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane.
[Geneva]: International Organization for Standardization, 1993 (plus amendments AM 1 through AM 7).
Unicode
The Unicode Consortium. The Unicode Standard, Version 2.0. Reading, Mass.: Addison-Wesley Developers Press,
1996.

A.2 OTRAS REFERENCIAS
Aho/Ullman
Aho, Alfred V., Ravi Sethi, and Jeffrey D. Ullman. Compilers: Principles, Techniques, and Tools. Reading:
Addison-Wesley, 1986, rpt. corr. 1988.
Berners-Lee et al.
Berners-Lee, T., R. Fielding, and L. Masinter. Uniform Resource Identifiers (URI): Generic Syntax and Semantics.
1997. (En progreso; ver actualizaciones en RFC1738.)
Brggemann-Klein
Brggemann-Klein, Anne. Regular Expressions into Finite Automata. Extended abstract in I. Simon, Hrsg., LATIN
1992, S. 97-98. Springer-Verlag, Berlin 1992. Full Version in Theoretical Computer Science 120: 197-213, 1993.
Brggemann-Klein and Wood
Brggemann-Klein, Anne, and Derick Wood. Deterministic Regular Languages. Universitt Freiburg, Institut fr
Informatik, Bericht 38, Oktober 1991.
Clark
James Clark. Comparison of SGML and XML. Ver http://www.w3.org/TR/NOTE-sgml-xml-971215.
IETF RFC1738
IETF (Internet Engineering Task Force).RFC 1738: Uniform Resource Locators (URL), ed. T. Berners-Lee, L.
Masinter, M. McCahill.1994.
IETF RFC1808
IETF (Internet Engineering Task Force). RFC 1808: Relative Uniform Resource Locators, ed. R. Fielding. 1995.
IETF RFC2141
IETF (Internet Engineering Task Force). RFC 2141: URN Syntax, ed. R. Moats. 1997.
ISO 8879
ISO (International Organization for Standardization). ISO 8879:1986(E). Information processing -- Text and
Office Systems -- Standard Generalized Markup Language (SGML). First edition -- 1986-10-15. [Geneva]:
International Organization for Standardization, 1986.
ISO/IEC 10744
Hypermedia/Time-based Structuring Language (HyTime). [Geneva]: International Organization for
Standardization, 1992. Extended Facilities Annexe. [Geneva]: International Organization for Standardization,
1996.

B. CLASES DE CARACTERES
Siguiendo con las caractersticas definidas en el estndar Unicode, los caracteres se clasifican en caracteres base (estos
contienen los caracteres alfabticos de alfabeto latino, sin smbolos diacrticos), caracteres ideogrficos y caracteres
combinatorios (que contienen a la mayora de caracteres diacrticos). Estas clases se combinan para formar la clase de
las letras (letters). Los dgitos y los 'extensores' tambin se distinguen.
Caracteres
[84] Letter ::= BaseChar | Ideographic
[85] BaseChar ::= [#x0041-#x005A] | [#x0061-#x007A] | [#x00C0-#x00D6] | [#x00D8-#x00F6] | [#x00F8-
#x00FF] | [#x0100-#x0131] | [#x0134-#x013E] | [#x0141-#x0148] | [#x014A-#x017E]
| [#x0180-#x01C3] | [#x01CD-#x01F0] | [#x01F4-#x01F5] | [#x01FA-#x0217] | [#x0250-
#x02A8] | [#x02BB-#x02C1] | #x0386 | [#x0388-#x038A] | #x038C | [#x038E-#x03A1]
| [#x03A3-#x03CE] | [#x03D0-#x03D6] | #x03DA | #x03DC | #x03DE | #x03E0 | [#x03E2-
#x03F3] | [#x0401-#x040C] | [#x040E-#x044F] | [#x0451-#x045C] | [#x045E-#x0481]
| [#x0490-#x04C4] | [#x04C7-#x04C8] | [#x04CB-#x04CC] | [#x04D0-#x04EB]
| [#x04EE-#x04F5] | [#x04F8-#x04F9] | [#x0531-#x0556] | #x0559 | [#x0561-#x0586]
| [#x05D0-#x05EA] | [#x05F0-#x05F2] | [#x0621-#x063A] | [#x0641-#x064A] | [#x0671-
#x06B7] | [#x06BA-#x06BE] | [#x06C0-#x06CE] | [#x06D0-#x06D3] | #x06D5 | [#x06E5-
#x06E6] | [#x0905-#x0939] | #x093D | [#x0958-#x0961] | [#x0985-#x098C] | [#x098F-

107 de 137

#x0990] | [#x0993-#x09A8] | [#x09AA-#x09B0] | #x09B2 | [#x09B6-#x09B9] | [#x09DC-
#x09DD] | [#x09DF-#x09E1] | [#x09F0-#x09F1] | [#x0A05-#x0A0A] | [#x0A0F-#x0A10]
| [#x0A13-#x0A28] | [#x0A2A-#x0A30] | [#x0A32-#x0A33] | [#x0A35-#x0A36] | [#x0A38-
#x0A39] | [#x0A59-#x0A5C] | #x0A5E | [#x0A72-#x0A74] | [#x0A85-#x0A8B] | #x0A8D
| [#x0A8F-#x0A91] | [#x0A93-#x0AA8] | [#x0AAA-#x0AB0] | [#x0AB2-#x0AB3]
| [#x0AB5-#x0AB9] | #x0ABD | #x0AE0 | [#x0B05-#x0B0C] | [#x0B0F-#x0B10] | [#x0B13-
#x0B28] | [#x0B2A-#x0B30] | [#x0B32-#x0B33] | [#x0B36-#x0B39] | #x0B3D | [#x0B5C-
#x0B5D] | [#x0B5F-#x0B61] | [#x0B85-#x0B8A] | [#x0B8E-#x0B90] | [#x0B92-#x0B95]
| [#x0B99-#x0B9A] | #x0B9C | [#x0B9E-#x0B9F] | [#x0BA3-#x0BA4] | [#x0BA8-#x0BAA]
| [#x0BAE-#x0BB5] | [#x0BB7-#x0BB9] | [#x0C05-#x0C0C] | [#x0C0E-#x0C10]
| [#x0C12-#x0C28] | [#x0C2A-#x0C33] | [#x0C35-#x0C39] | [#x0C60-#x0C61]
| [#x0C85-#x0C8C] | [#x0C8E-#x0C90] | [#x0C92-#x0CA8] | [#x0CAA-#x0CB3]
| [#x0CB5-#x0CB9] | #x0CDE | [#x0CE0-#x0CE1] | [#x0D05-#x0D0C] | [#x0D0E-#x0D10]
| [#x0D12-#x0D28] | [#x0D2A-#x0D39] | [#x0D60-#x0D61] | [#x0E01-#x0E2E] | #x0E30
| [#x0E32-#x0E33] | [#x0E40-#x0E45] | [#x0E81-#x0E82] | #x0E84 | [#x0E87-#x0E88]
| #x0E8A | #x0E8D | [#x0E94-#x0E97] | [#x0E99-#x0E9F] | [#x0EA1-#x0EA3] | #x0EA5
| #x0EA7 | [#x0EAA-#x0EAB] | [#x0EAD-#x0EAE] | #x0EB0 | [#x0EB2-#x0EB3] | #x0EBD
| [#x0EC0-#x0EC4] | [#x0F40-#x0F47] | [#x0F49-#x0F69] | [#x10A0-#x10C5] | [#x10D0-
#x10F6] | #x1100 | [#x1102-#x1103] | [#x1105-#x1107] | #x1109 | [#x110B-#x110C]
| [#x110E-#x1112] | #x113C | #x113E | #x1140 | #x114C | #x114E | #x1150 | [#x1154-
#x1155] | #x1159 | [#x115F-#x1161] | #x1163 | #x1165 | #x1167 | #x1169 | [#x116D-
#x116E] | [#x1172-#x1173] | #x1175 | #x119E | #x11A8 | #x11AB | [#x11AE-#x11AF]
| [#x11B7-#x11B8] | #x11BA | [#x11BC-#x11C2] | #x11EB | #x11F0 | #x11F9 | [#x1E00-
#x1E9B] | [#x1EA0-#x1EF9] | [#x1F00-#x1F15] | [#x1F18-#x1F1D] | [#x1F20-#x1F45]
| [#x1F48-#x1F4D] | [#x1F50-#x1F57] | #x1F59 | #x1F5B | #x1F5D | [#x1F5F-#x1F7D]
| [#x1F80-#x1FB4] | [#x1FB6-#x1FBC] | #x1FBE | [#x1FC2-#x1FC4] | [#x1FC6-#x1FCC]
| [#x1FD0-#x1FD3] | [#x1FD6-#x1FDB] | [#x1FE0-#x1FEC] | [#x1FF2-#x1FF4] | [#x1FF6-
#x1FFC] | #x2126 | [#x212A-#x212B] | #x212E | [#x2180-#x2182] | [#x3041-#x3094]
| [#x30A1-#x30FA] | [#x3105-#x312C] | [#xAC00-#xD7A3]
[86] Ideographic ::= [#x4E00-#x9FA5] | #x3007 | [#x3021-#x3029]
[87] CombiningChar ::= [#x0300-#x0345] | [#x0360-#x0361] | [#x0483-#x0486] | [#x0591-#x05A1] | [#x05A3-
#x05B9] | [#x05BB-#x05BD] | #x05BF | [#x05C1-#x05C2] | #x05C4 | [#x064B-#x0652]
| #x0670 | [#x06D6-#x06DC] | [#x06DD-#x06DF] | [#x06E0-#x06E4] | [#x06E7-#x06E8]
| [#x06EA-#x06ED] | [#x0901-#x0903] | #x093C | [#x093E-#x094C] | #x094D | [#x0951-
#x0954] | [#x0962-#x0963] | [#x0981-#x0983] | #x09BC | #x09BE | #x09BF | [#x09C0-
#x09C4] | [#x09C7-#x09C8] | [#x09CB-#x09CD] | #x09D7 | [#x09E2-#x09E3] | #x0A02
| #x0A3C | #x0A3E | #x0A3F | [#x0A40-#x0A42] | [#x0A47-#x0A48] | [#x0A4B-#x0A4D]
| [#x0A70-#x0A71] | [#x0A81-#x0A83] | #x0ABC | [#x0ABE-#x0AC5] | [#x0AC7-#x0AC9]
| [#x0ACB-#x0ACD] | [#x0B01-#x0B03] | #x0B3C | [#x0B3E-#x0B43] | [#x0B47-#x0B48]
| [#x0B4B-#x0B4D] | [#x0B56-#x0B57] | [#x0B82-#x0B83] | [#x0BBE-#x0BC2]
| [#x0BC6-#x0BC8] | [#x0BCA-#x0BCD] | #x0BD7 | [#x0C01-#x0C03] | [#x0C3E-#x0C44]
| [#x0C46-#x0C48] | [#x0C4A-#x0C4D] | [#x0C55-#x0C56] | [#x0C82-#x0C83]
| [#x0CBE-#x0CC4] | [#x0CC6-#x0CC8] | [#x0CCA-#x0CCD] | [#x0CD5-#x0CD6]
| [#x0D02-#x0D03] | [#x0D3E-#x0D43] | [#x0D46-#x0D48] | [#x0D4A-#x0D4D] | #x0D57
| #x0E31 | [#x0E34-#x0E3A] | [#x0E47-#x0E4E] | #x0EB1 | [#x0EB4-#x0EB9] | [#x0EBB-
#x0EBC] | [#x0EC8-#x0ECD] | [#x0F18-#x0F19] | #x0F35 | #x0F37 | #x0F39 | #x0F3E
| #x0F3F | [#x0F71-#x0F84] | [#x0F86-#x0F8B] | [#x0F90-#x0F95] | #x0F97 | [#x0F99-
#x0FAD] | [#x0FB1-#x0FB7] | #x0FB9 | [#x20D0-#x20DC] | #x20E1 | [#x302A-#x302F]
| #x3099 | #x309A
[88] Digit ::= [#x0030-#x0039] | [#x0660-#x0669] | [#x06F0-#x06F9] | [#x0966-#x096F] | [#x09E6-
#x09EF] | [#x0A66-#x0A6F] | [#x0AE6-#x0AEF] | [#x0B66-#x0B6F] | [#x0BE7-#x0BEF]
| [#x0C66-#x0C6F] | [#x0CE6-#x0CEF] | [#x0D66-#x0D6F] | [#x0E50-#x0E59] | [#x0ED0-
#x0ED9] | [#x0F20-#x0F29]
[89] Extender ::= #x00B7 | #x02D0 | #x02D1 | #x0387 | #x0640 | #x0E46 | #x0EC6 | #x3005 | [#x3031-
#x3035] | [#x309D-#x309E] | [#x30FC-#x30FE]
Las clases de caracteres definidas aqu pueden ser derivadas de la base de datos Unicode, de la siguiente manera:
Los caracteres de comienzo de nombre deben poseer una de las siguientes categoras: Ll, Lu, Lo, Lt, Nl.
Los caracteres de nombres, salvo los caracteres de comienzo de nombre deben poseer una de las siguientes
categoras: Mc, Me, Mn, Lm, Nd.
Los caracteres en el rea de compatibilidad (p.e. con cdigos de carcter superiores a #xF900 e inferiores a
#xFFFE) no estn permitidos en los nombres XML.

108 de 137

Los caracteres que tengan fuentes o compatibilidades de descomposicin (p.e. los que tengan la "etiqueta de
formato de compatibilidad" en el quinto campo de la base de datos -- indicado por el campo 5 que comienza con
un "<") no estn permitidos.
Los siguientes caracteres son tratados como caracteres de comienzo de nombre ms que como caracteres de
nombre, porque el fichero de propiedades los clasifica como alfabticos: [#x02BB-#x02C1], #x0559, #x06E5,
#x06E6.
Los caracteres #x20DD-#x20E0 son excluidos (de acuerdo con Unicode, seccin 5.14).
El carcter #x00B7 se clasifica como 'extensor', porque la as lo identifica la lista de propiedades.
El carcter #x0387 se aade como un carcter de nombre, porque #x00B7 es su equivalente cannico.
Los caracteres ':' y '_' estn permitidos como caracteres de comienzo de nombre.
Los caracteres '-' y '.' estn permitidos como caracteres de nombre.

C. XML Y SGML (NO NORMATIVO)
XML est diseado para ser un subconjunto de SGML, por lo tanto todo documento XML vlido tambin debe ser un
documento SGML "conformado". Para una comparacin detallada de las restricciones adicionales que XML impone a los
documentos SGML, ver [Clark].

D. EXPANSIN DE REFERENCIAS A ENTIDADES Y CARACTERES (NO NORMATIVO)
Este apndice contiene algunos ejemplos que ilustran la secuencia de reconocimiento de referencias a entidades y
caracteres y su expansin, como se especifica en la seccin "4.4 Tratamiento de Entidades y Referencias por el
Procesador XML".
Si la DTD contiene la declaracin
<!ENTITY ejemplo "<p>Un ampersand (&) puede ser "escapado"
numricamente (&#38;) o con una entidad general
(&).</p>" >
entonces el procesador XML reconocer las referencias a caracteres cuando analice la declaracin de entidad, y las
resolver antes de almacenar la siguiente cadena como el valor de la entidad "ejemplo":
<p>Un ampersand (&) puede ser "escapado"
(&).</p>
Una referencia en el documento a "&ejemplo;" causar que se reanalice el texto, al tiempo que las etiquetas de comienzo
y de fin del elemento "p" sern reconocidas y las tres referencias sern reconocidas y expandidas, resultando un
elemento "p" con el siguiente contenido (todos los datos, sin delimitadores ni marcas):
Un ampersand (&) puede ser "escapado"
(&).
Un ejemplo algo ms complejo puede ilustrar las reglas y sus todos sus efectos. En el siguiente ejemplo, los nmeros de
lnea slo son una referencia.
1 <?xml version='1.0'?>
2 <!DOCTYPE prueba [
3 <!ELEMENT prueba (#PCDATA) >
4 <!ENTITY % xx '%zz;'>
5 <!ENTITY % zz '<!ENTITY falso "error" >' >
6 %xx;
7 ]>
8 <prueba>Este ejemplo muestra un mtodo &falso;.</prueba>

109 de 137

Esto produce lo siguiente:
en la lnea 4, la referencia al carcter 37 se expande inmediatamente y la entidad parmetro "xx" se almacena
en el tabla de smbolos con el valor "%zz;". Dado que el texto de reemplazo no es reledo, la referencia a la
entidad parmetro "zz" no es reconocida. (y se producir un error si "zz" no estuviese declarado todava.)
en la lnea 5, la referencia a carcter "<" se expande inmediatamente y la entidad parmetro "zz" se
almacena con el texto de reemplazo "<!ENTITY falso "error" >", que es una declaracin de entidad bien-
formada.
en la lnea 6, la referencia a "xx" se reconoce, y se analiza el texto reemplazo de "xx" (llamado "%zz;"). La
referencia a "zz" se reconoce en su turno, y se analiza el texto de reemplazo ("<!ENTITY falso "error" >"). La
entidad general "falso" ha sido declara en este momento, con el texto de reemplazo "error".
en la lnea 8, la referencia a la entidad general "falso" es reconocida, y se expande, por lo que el contenido
completo del elemento "prueba" es la cadena autodescrita Este ejemplo muestra un mtodo error.

E. MODELOS DE CONTENIDO DETERMINISTAS (NO NORMATIVO)
Por compatibilidad, se requiere que los modelos de contenido en las declaraciones de tipo de elemento sean
determinsticas.
SGML requiere modelos de contenido determinsticos (se denominan "no ambiguos"). Los procesadores XML construidos
utilizando sistemas SGML pueden indicar modelos de contenido no determinsticos como errores.
Por ejemplo, el modelo de contenido ((b, c) | (b, d)) no es determinstico porque dada una b inicial, el 'parser' no puede
saber que b del modelo se est tomando sin "mirar adelante" para ver que elemento sigue a esa b. En este caso, las dos
referencias a b pueden ser reducidas a una haciendo que el modelo lea (b, (c | d)). Una b inicial, ahora, slo se iguala a
un nico modelo de contenido. El 'parser' no necesita "mirar adelante" para ver que sigue, si una c o una d, las dos se
aceptarn.
Ms formalmente: se puede construir un autmata de estados finitos partiendo del modelo de contenido, mediante la
utilizacin de algoritmos estndares (p.e. el algoritmo 3.5 de la seccin 3.9 de Aho, Sethi y Ullman [Aho/Ullman]). En
muchos otros algoritmos, se construye un conjunto para cada posicin de una expresin regular (p.e. cada nodo hoja en
el rbol sintctico de una expresin regular). Si cualquier posicin tiene un conjunto en el cual ms de una posicin est
etiquetada con el mismo nombre de tipo de elemento, el modelo de contenido es errneo y hay que informar de su
existencia.
Existen algoritmos que permiten reducir automticamente muchos, pero no todos los modelos de contenido no
determinsticos a determinsticos. Ver Brggemann-Klein 1991 [Brggemann-Klein].

F. AUTODETECCIN DE LA CODIFICACIN (NO NORMATIVO)
La declaracin de codificacin XML funciona como una etiqueta interna en cada entidad, indicando que codificacin de
caracteres se est utilizando. Antes de que un procesador XML pueda leer la etiqueta interna, sin embargo, ste debe
aparentemente, conocer que codificacin de caracteres se est utilizando - que es lo que est intentando indicar la
etiqueta interna -. En XML esto se limita de dos maneras: se asume que cada implementacin debe soportar slo un
conjunto finito de codificaciones de caracteres, y la declaracin de codificacin de XML est restringida en posicin y
contenido, para hacerla ms sencilla para la autodeteccin de la codificacin que se est utilizando en cada entidad.
Adems, en muchos casos, tambin estn disponibles adicionalmente otras fuentes de informacin, a parte de las
cadenas de datos XML. Los dos casos pueden ser distinguidos, dependiendo de si la entidad XML est presente en el
procesador sin, o con, alguna informacin externa. Siempre consideramos la primera opcin primero.
Dado que cada entidad XML que no pertenezca a los formatos UTF-8 o UTF-16 debe comenzar con una declaracin de
codificacin XML, donde los primeros caracteres deben ser '<?xml', cualquier 'procesador conformador' puede detectar,
despus de dos a cuatro octetos de entrada, cual de los siguientes casos a aplicar. Al leer esta lista, puede ayudar el
conocer que en UCS-4, '<' es "#x0000003C" y '?' es "#x0000003F", y el 'Byte Order Mark' requerido de las cadenas de
datos UTF-16 es "#xFEFF".
00 00 00 3C: UCS-4, big-endian machine (1234 order)
3C 00 00 00: UCS-4, little-endian machine (4321 order)
00 00 3C 00: UCS-4, unusual octet order (2143)

110 de 137

00 3C 00 00: UCS-4, unusual octet order (3412)
FE FF: UTF-16, big-endian
FF FE: UTF-16, little-endian
00 3C 00 3F: UTF-16, big-endian, no Byte Order Mark
3C 00 3F 00: UTF-16, little-endian, no Byte Order Mark
3C 3F 78 6D: UTF-8, ISO 646, ASCII, alguna parte de ISO 8859, Shift-JIS, EUC, o cualquier otra codificacin en
7-bit, 8-bit hbrida, que asegure que los caracteres ASCII tienen su posicin, anchura y valores normales. La
declaracin de codificacin actual debe ser leda para detectar cual de estas aplicar, pero dado que todas estas
codificaciones utilizan los mismos patrones de bits para los caracteres ASCII, la declaracin de codificacin debe
ser leda de manera exacta
4C 6F A7 94: EBCDIC (toda la declaracin de codificacin debe ser leda para indicar que pgina de cdigo se
est utilizando)
otra: UTF-8 sin una declaracin de codificacin, o la cadena de datos est corrupta, fragmentada o con errores
Este nivel de autodeteccin es suficiente para leer la declaracin de codificacin XML y para analizar el identificador de
codificacin de caracteres, que sigue siendo necesario para distinguir los miembros individuales de cada familia de
codificaciones (p.e. para indicar desde UTF-8 a 8859, y las partes de 8859 entre ellas, o para distinguir la pgina del
cdigo EBCDIC especifica en uso, etc).
Dado que los contenidos de la declaracin de codificacin estn restringidos a caracteres ASCII, los procesadores pueden
leer con exactitud toda la declaracin de codificacin tan pronto como hayan detectado que familia de codificaciones est
en uso. En la prctica, todas las codificaciones ampliamente utilizadas entran en alguna de las categoras descritas arriba.
La declaracin de codificacin XML permite un razonable aseguramiento del etiquetado de codificacin de caracteres,
incluso cuando fuentes externas de informacin en el sistema operativo o el nivel de protocolo de transporte no lo
aseguren.
Una vez que el procesador ha detectado la codificacin en uso, puede actuar apropiadamente, bien invocando a una
rutina de entrada externa para cada caso, o bien llamando a la funcin de conversin apropiada para cada carcter de
entrada.
Como cualquier sistema de 'auto-etiquetado', la declaracin de codificacin de XML no funcionar si cualquier software
cambia el conjunto de caracteres o la codificacin de la entidad sin actualizar dicha declaracin. Los implementadores de
rutinas de codificacin de caracteres deberan ser cuidadosos para asegurar exactitud de la informacin interna y externa
utilizada para etiquetar la entidad.
El segundo caso posible ocurre cuando la entidad XML est acompaada de informacin de codificacin, como en algunos
sistemas de archivos y algunos protocolos de red. Cuando mltiples fuentes de informacin estn disponibles, su
prioridad relativa y el mtodo preferido para el manejo de conflictos debe ser especificado como parte de un protocolo de
mayor nivel utilizado para enviar XML. Las reglas para la prioridad relativa de la etiqueta interna y la etiqueta de tipo
MIME en una cabecera externa, por ejemplo, deberan ser parte del documento RFC que definira los tipos MIME
"text/xml" y "application/xml". Por razones de interoperatividad, sin embargo, se recomiendan las siguientes reglas.
Si una entidad XML est en un archivo, la 'Byte-Order Mark' y la PI de declaracin de codificacin se utilizan (si
estn presentes) para determinar la codificacin de los caracteres. El resto de heursticas y fuentes de
informacin slo se utilizan para recuperacin de errores.
Si una entidad XML se enva con un tipo MIME de "text/xml", el parmetro 'conjunto de caracteres (charset)' del
tipo MIME determina el mtodo de codificacin de caracteres. El resto de heursticas y fuentes de informacin
slo se utilizan para recuperacin de errores.
Si una entidad XML se enva con un tipo MIME de "application/xml", la 'Byte-Order Mark' y la PI de declaracin
de codificacin (si est presente) se utilizan para determinar la codificacin de los caracteres. El resto de
heursticas y fuentes de informacin slo se utilizan para recuperacin de errores.
Estas reglas se aplican slo en la ausencia de documentacin de nivel de protocolo, en particular, cuando los tipos MIME
"text/xml" y "application/xml" son definidos. Las recomendaciones de los RFC relevantes invalidan estas reglas.

G. GRUPO DE TRABAJO XML DEL W3C (NO NORMATIVO)

111 de 137
Esta especificacin ha sido preparada y aprobada para su publicacin por el Grupo de Trabajo (GT) XML del W3C. La
aprobacin de esta especificacin por parte del GT no implica necesariamente que todos los miembros del GT hayan
votado su aprobacin. Los miembros actuales del GT XML son:
Jon Bosak, Sun (Presidente); James Clark (Direccin Tcnica); Tim Bray, Textuality y Netscape (Co-editor XML); Jean
Paoli, Microsoft (Co-editor XML); C. M. Sperberg-McQueen, U. of Illinois (Co-editor XML); Dan Connolly, W3C (Enlace con
el W3C); Paula Angerstein, Texcel; Steve DeRose, INSO; Dave Hollander, HP; Eliot Kimber, ISOGEN; Eve Maler,
ArborText; Tom Magliery, NCSA; Murray Maloney, Muzmo y Grif; Makoto Murata, Fuji Xerox Information Systems; Joel
Nava, Adobe; Conleth O'Connell, Vignette; Peter Sharpe, SoftQuad; John Tigue, DataChannel

ANEXO 2: XML SCHEMA W3C Working Draft Mayo 1999 (ingls).

112 de 137
XML SCHEMA PART 2: DATATYPES
World Wide Web Consortium Working Draft 06-May-1999

THI S VERSI ON
http://www.w3.org/1999/05/06-xmlschema-2/
(with accompanying schema and DTD)

LATEST VERSI ON:
http://www.w3.org/TR/xmlschema-2/

EDI TORS:
Paul V. Biron (Kaiser Permanente, for Health Level Seven) <Paul.V.Biron@kp.org>
Ashok Malhotra (IBM) <petsa@us.ibm.com>
Copyright 1999 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability,trademark, document use and
software licensing rules apply.

STATUS OF THI S DOCUMENT
This is a W3C Working Draft for review by members of the W3C and other interested parties in the general
public.
It has been reviewed by the XML Schema Working Group and the Working Group has agreed to its
publication. Note that not that all sections of the draft represent the current consensus of the WG. Different
sections of the specification may well command different levels of consensus in the WG. Public comments on
this draft will be instrumental in the WG's deliberations.
Please review and send comments to www-xml-schema-comments@w3.org ( archive).
The facilities described herein are in a preliminary state of design. The Working Group anticipates substantial
changes, both in the mechanisms described herein, and in additional functions yet to be described. The
present version should not be implemented except as a check on the design and to allow experimentation
with alternative designs. The Schema WG will not allow early implementation to constrain its ability to make
changes to this specification prior to final release.
A list of current W3C working drafts can be found at http://www.w3.org/TR. They may be updated, replaced,
or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference
material or to cite them as other than "work in progress".
Ed. Note: Several "note types" are used throughout this draft:
issue [Issue (issue-name): ]
something on which the editors are seeking comment
editorial note [Ed. Note: ]
something the editors wish to call to the attention of the reader. To be removed prior to the
recommendation becoming final.
note [Note: ]
something the editors wish to call to the attention of the reader. To remain in the final recommendation.

ABSTRACT
This document specifies a language for defining datatypes to be used in XML Schemas and, possibly,
elsewhere.

TABLE OF CONTENTS
1. Introduction
1.1 Purpose

113 de 137

1.2 Requirements
1.3 Scope
1.4 Terminology
1.5 Organization
2. Type System
2.1 Datatype
2.2 Value space
2.3 Lexical Space
2.4 Characterizing operations
2.4.1 Equal
2.5 Facets
2.5.1 Fundamental facets
2.5.2 Constraining or Non-fundamental facets
2.6 Datatype dichotomies
2.6.1 Atomic vs. aggregate datatypes
2.6.2 Primitive vs. generated datatypes
2.6.3 Built-in vs. user-generated datatypes
3. Built-in datatypes
3.1 Namespace considerations
3.2 Primitive datatypes
3.2.1 ID
3.2.2 IDREF
3.2.3 IDREFS
3.2.4 ENTITY
3.2.5 ENTITIES
3.2.6 NMTOKEN
3.2.7 NMTOKENS
3.2.8 NOTATION
3.2.9 string
3.2.10 boolean
3.2.11 number
3.2.12 dateTime
3.2.13 binary
3.2.14 uri
3.3 Generated datatypes
3.3.1 integer
3.3.2 decimal
3.3.3 real
3.3.4 date
3.3.5 time
3.3.6 timePeriod
4. User-generated datatypes
5. Conformance

APPENDI CES
A. Schema for Datatype Definitions (normative)
B. DTD for Datatype Definitions (normative)
C. Built-in Generated Datatype Definitions (normative)
D. Pictures
E. Regular Expressions
F. References
G. Open Issues

1. I NTRODUCTI ON

1.1 PURPOSE
The [XML] specification defines a limited array of facilities for applying datatypes to document content in that
documents may contain or refer to DTDs that assign types to elements and attributes. However, document
authors, including authors of traditional documents and those transporting data in XML, often require a high
degree of type checking to ensure robustness in document understanding and data interchange.
The table below offers two typical examples of XML instances in which datatypes are implicit: the instance on
the left represents a billing invoice, the instance on the right a memo or perhaps an email message in XML.
Data oriented Document oriented
<invoice> <memo importance="high"

114 de 137

Data oriented Document oriented
<orderDate>Jan 21, 1999</orderDate>
<shipDate>Jan 25, 1999</shipDate>
<billingAddress>
<name>Ashok Malhotra</name>
<street>123 IBM Ave.</street>
<city>Hawthorne</city>
<state>NY</state>
<zip>10532-0000</zip>
</billingAddress>
<voice>555-1234</voice>
<fax>555-4321</fax>
</invoice>

date="03/23/1999">
<from>Paul V. Biron</from>
<to>Ashok Malhotra</to>
<subject>Latest draft</subject>
<body>
We need to discuss the latest
draft <emph>immediately</emph>.
Either email me at <email>
mailto:paul.v.biron@kp.org</email>
or call <phone>555-9876</phone>
</body>
</memo>

The invoice contains several dates and telephone numbers, a state (which comes from an enumerated list of
values), and a zip code (which has a definable regularity of expression). The memo contains many of the
same types of information: a date, a telephone number, an email address and an "importance" value (which
undoubtedly comes from an enumerated list, such as "low", "medium" or "high"). Applications which process
invoices and memos need to raise exceptions if something that was supposed to be a date or a telephone
number does not conform to the rules for valid dates or telephone numbers.
In both cases, validity constraints exist on the content of the instances that are not expressible in XML DTDs.
The limited datatyping facilities in XML have prevented validating XML processors from supplying the rigorous
type checking required in these situations. The result has been that application writers have had to implement
type checking in an ad hoc manner. This specification addresses the needs of both document authors and
applications writers for a robust, extensible datatype system for XML which could be incorporated into XML
processors. As discussed below, these datatypes can be used in other XML-related standards as well.

1.2 REQUI REMENTS
The [XML Schema Requirements] document spells out concrete requirements to be fulfilled by this
specification. This states that the XML Schema Language must:
1. provide for primitive data typing, including byte, date, integer, sequence, SQL & Java primitive data
types, etc.;
2. define a type system that is adequate for import/export from database systems (e.g., relational,
object, OLAP);
3. distinguish requirements relating to lexical data representation vs. those governing an underlying
information set;
4. allow creation of user-defined datatypes, such as datatypes that are derived from existing datatypes
and which may constrain certain of its properties (e.g., range, precision, length, mask).

1.3 SCOPE
This portion of the XML Schema Language discusses datatypes that can be used in a XML Schema. These
datatypes can be specified for element content that would be specified as #PCDATA and attribute values of
various types in a DTD. It is the intension of this specification that it be usable outside of the context of XML
Schemas for a wide range of other XML-related activities such as [XSL] and [RDF Schema].
For the most part, this specification discusses what are sometimes referred to as scalar datatypes in that they
constrain the lexical representation of a single literal. In some cases, as for example in [IDREFS],
[ENTITIES] and [NMTOKENS], the value may consist of a list or set of literals separated by spaces. This is
an example of what is called an aggregate datatype. Future versions of this specification will contain a more
general mechanism for defining and using aggregate (collection) datatypes such as sets, bags and records.

1.4 TERMI NOLOGY
Ed. Note: if necessary, insert a terminology list (e.g., may, must, datatype valid, etc.)

115 de 137

1.5 ORGANI ZATI ON
Following this introduction, the remainder of this specification is organized into three main sections: [Type
System] describes the conceptual framework upon which the datatype system is constructed; [Built-in
datatypes] details the complete list of datatypes which all conforming processors must implement; [User-
generated datatypes] discusses how to define specialized types from the built-in types and [Conformance]
specifies the general rules concerning conforming processors.

2. TYPE SYSTEM
This section describes the conceptual framework behind the type system defined in this specification. The
framework has been influenced by the [ISO 11404] standard on language-independent datatypes as well as
the datatypes for [SQL] and for programming languages such as Java.
The datatypes discussed in this specification are computer representations of well known abstract concepts
such as integer and date. It is not the place of this specification to define these concepts. Many other
publications provide excellent definitions.
Two concepts are essential for an understanding of datatypes as they are discussed here: a value space is an
abstract collection of permitted values for the datatype. Each datatype also has a space of valid lexical
representations or literals. A single value in the value space may map to several valid literals.

2.1 DATATYPE
[Definition: ] In this specification, a datatype has a set of distinct values, called its value space, and is
characterized by facets and/or properties of those values and by operations on or resulting in those values.
Further, each datatype is characterized by a space consisting of valid lexical representations for each value in
the value space.

2.2 VALUE SPACE
A value space is a abstract collection of permitted values for the datatype. Value spaces have certain
properties. For example, they always have the concept of cardinality and equality and may have the concept
of order by which individual values within the value space can be compared to one another. Value spaces may
also support operations on values such as addition.
[Definition: ] A value space is the collection of permitted values for a given datatype. The value space of a
given datatype can be defined in one of the following ways:
enumerated outright, sometimes referred to as an extensional definition
defined axiomatically from fundamental notions, sometimes referred to as an intensional definition
defined as the subset of values from an already defined value space with a given set of properties
defined as a combination of values from some already defined value space by a specific construction
procedure

2.3 LEXI CAL SPACE
In addition to its value space, each datatype has a lexical representation space. [Definition: ] The lexical
space for a datatype consists of a set of valid literals. Each value in the datatype's value space maps to one
or more valid literals in its lexical space. For example, "100.0" and "1.0E2" are two different representations
for the same value. Depending on the situation, either or both of these representations might be acceptable.
The type system defined in this specification provides a mechanism for schema designers to control the value
set as well as the acceptable lexical representations of the values in the value space of a datatype. Each
[Primitive datatypes] definition includes a detailed description of the default lexical space.

2.4 CHARACTERI ZI NG OPERATI ONS

116 de 137

Many different datatypes may share the same value space. As a result, a datatype is only partially defined by
its value space. [Definition: ] The characterizing operations for a datatype are those operations (such as
"add" or "append") on or resulting in values of the datatype which distinguish this datatype from other
datatypes having value spaces which are identical except possibly for substitution of literals.
Characterizing operations can be useful in choosing the appropriate datatype for particular purposes, such as
mapping to or from common programming languages or database environments.
Ed. Note: Currently, no characterizing operations are defined on the built-in datatypes
provided by this specification; additionally, there is no means to specify characterizing
operations on user-generated datatypes. This will be addressed in a future draft.
This discussion of characterizing operations in the definition of datatype is for pedagogical purposes only and
does not imply that conforming processors must implement those operations, nor does it imply that
expressions (containing operators) which evaluate to a given datatype will be accepted by conforming XML
processors.

2.4.1 EQUAL
Every value space supports the notion of equality, with the following rules:
for any two instances of values from the value space (a, b), either a is equal to b, denoted a = b, or
a is not equal to b, denoted a b;
there is no pair of instances (a, b) of values from the value space such that both a = b and a b;
for every value a from the value space, a = a;
for any two instances (a, b) of values from the value space, a = b if and only if b = a;
for any three instances (a, b, c) of values from the value space, if a = b and b = c, then a = c.
On every datatype, the operation Equal is defined in terms of the equality property of the value space: for
any values a, b drawn from the value space, Equal(a,b) is true if a = b, and false otherwise.

2.5 FACETS
[Definition: ] A facet is a single defining aspect of a concept or an object. Generally speaking, each facet of
an item characterizes that item along independent aspects or dimensions.
The facets of a datatype serve to distinguish those aspects of one datatype which differ from other datatypes.
Rather than being defined solely in terms of a prose description the datatypes in this specification are defined
in terms of the synthesis of facet values which together determine the value space and properties of the
datatype.
Facets are of two types: fundamental facets that define the datatype and non-fundamental or constraining
facets that constrain the permitted values of a datatype.

2.5.1 FUNDAMENTAL FACETS
Datatypes are characterized by properties of their value spaces. These optional properties are discussed in
this section. Each of these properties give rise to a facet that serves to characterize the datatype.

2.5.1.1 ORDER
[Definition: ] A value space, and hence a datatype, is said to be ordered if there exists an order relation
defined for that value space. Order relations have the following rules:
for every pair (a, b) from the value space, either a b or b a, or a = b;
for every triple (a, b, c) from the value space, if a b and b c, then a c.

117 de 137

If a value space is ordered, then the datatype will have a corresponding [Characterizing operations], called
InOrder(a, b), defined by:
for every (a, b) from the value space, InOrder(a, b) is true if a b, and false otherwise.
There may exist several possible order relations for a given value space. Additionally, there may exist multiple
datatypes with the same value space. In such cases, each datatype will define a different order relation on
the value space.
Ed. Note: Currently, no order relations are defined on the built-in datatypes provided by
this specification; additionally, there is no means to specify an order relation on user-
generated datatypes. This will be addressed in a future draft.

2.5.1.2 BOUNDS
Some ordered value spaces, and hence some datatypes, are said to be bounded. [Definition: ] A value space
is bounded above if there exists a unique value U in the value space such that, for all values v in the value
space, v U. The value U is said to be an upper bound of the value space. [Definition: ] A value space is
bounded below if there exists a unique value L in the space such that, for all values v in the value space, L
v. The value L is then said to be a lower bound of the value space.
[Definition: ] A datatype is bounded if its value space has both an upper and a lower bound.

2.5.1.3 CARDI NALI TY
[Definition: ] Every value space has associated with it the concept of cardinality. Some value spaces are
finite, some are countably infinite while still others are uncountably infinite. A datatype is said to have the
cardinality of its value space. It is sometimes useful to categorize value spaces ( and hence, datatypes) as to
their cardinality. There are three significant cases:
value spaces that are finite
value spaces that are countably infinite and exact (see [Exact and Approximate])
value spaces that are countably infinite and approximate (see [Exact and Approximate])
Every conceptually finite value space is necessarily exact. No computational datatype is uncountably infinite.
Ed. Note: Currently, cardinality is not specified for the built-in datatypes provided by this
specification; additionally, there is no means to specify a cardinality on user-generated
datatypes. This will be addressed in a future draft.

2.5.1.4 EXACT AND APPROXI MATE
The computational model of a datatype may limit the degree to which values of the datatype can be
distinguished. If every value in the value space of the conceptual datatype is distinguishable in the
computational model from every other value in the value space, then the datatype is said to be exact.
Certain mathematical datatypes having values which do not have finite representations are said to be
approximate, in the following sense:
Let M be the mathematical datatype and C be the corresponding computational datatype,
and let P be the mapping from the value space of M to the value space of C. Then for every
value v' in C, there is a corresponding value v in M and a real value h such that P(x) = v' for
all X in M such that |v - x| < h. That is, v' is the approximation in C to all values in M which
are "within distance h of value v". Furthermore, for at least one value v' in C, there is more
than one value y in M such that P(y) = v' And thus C is not an exact model of M.
In this specification, all approximate datatypes have computational models which specify, via parametric
values, a degree of approximation, that is, they require a certain minimum set of values of the mathematical
datatype to be distinguishable in the computational datatype.

118 de 137

Ed. Note: Currently, exactness is not specified for the built-in datatypes provided by this
specification; additionally, there is no means to specify a exactness for user-generated
datatypes. This will be addressed in a future draft.

2.5.1.5 NUMERI C
A datatype is said to be numeric if its values are conceptually quantities (in some mathematical number
system). A datatype whose values do not have this property is said to be non-numeric.

2.5.2 CONSTRAI NI NG OR NON- FUNDAMENTAL FACETS
Constraining facets are optional properties that can be applied to a datatype to (further) constrain its value
space. Constraining the value space consequently constrains the allowed lexical representations. Adding
constraining facets to a [Base type] is used to define [User-generated datatypes].
Ed. Note: should we consider units/dimensionality now? or wait for a further draft? Note
that [timePeriod] implicitly has units.

2.5.2.1 LENGTH
[Definition: ] For the [string] datatype, length specifies the maximum number of allowable characters in the
string. For the [binary] datatype it specifies the maximum length in bytes.
Ed. Note: We need to ultimately reconcile the notion of string length with the resolution of
the i18n issues around character, indexing, etc.

2.5.2.2 MAXI MUM LENGTH
[Definition: ] The maxlength facet indicates the maximum length, in bytes, of a [string] datatype for which
the length facet is not specified.

2.5.2.3 LEXI CAL REPRESENTATI ON
The datatypes defined in this specification are defined in terms of abstract value spaces and their properties
as opposed to how values are lexically represented in XML instances. However, the lexical representation of
values is of prime importance in many applications. Because of this importance, each [Primitive datatypes]
definition includes a detailed description of its default [Lexical Space]. [Definition: ] The lexical
representation facet can be used to constrain the allowable representations, or literals, for values of a
datatype. The meaning of the lexical representation facet depends on the datatype to which it is applied.
For example, for [string], values for the lexical representation facet are either [Pictures] or [Regular
Expressions], while for [dateTime], values are derived from [ISO 8601] and [SQL].

2.5.2.4 ENUMERATI ON
[Definition: ] Presence of an enumeration facet constrains the value space of the datatype to one of the
specified list. The enumeration facet can be applied to any datatype. No order or any other relationship is
implied between the elements of the enumeration list.

2.5.2.5 MAXI NCLUSI VE
[Definition: ] The maxInclusive facet determines the upper bound of the value space for a datatype with the
[Order] property. The maximum value specified with this facet is inclusive in the sense that the value
specified for the facet is itself included in the value space for the datatype.

2.5.2.6 MAXEXCLUSI VE

119 de 137

[Definition: ] The maxExclusive facet determines the upper bound of the value space for a datatype with the
[Order] property. The maximum value specified with this facet is exclusive in the sense that the value
specified for the facet is itself excluded from the value space for the datatype.

2.5.2.7 MI NI NCLUSI VE
[Definition: ] The minInclusive facet determines the lower bound of the value space for a datatype with the
[Order] property. The minimum value specified with this facet is inclusive in the sense that the value
specified for the facet is itself included in the value space for the datatype.

2.5.2.8 MI NEXCLUSI VE
[Definition: ] The minExclusive facet determines the lower bound of the value space for a datatype with the
[Order] property. The minimum value specified with this facet is exclusive in the sense that the value
specified for the facet is itself excluded from the value space for the datatype.

2.6 DATATYPE DI CHOTOMI ES
It is useful to categorize the datatypes defined in this specification along various dimensions, forming a set of
characterization dichotomies.

2.6.1 ATOMI C VS. AGGREGATE DATATYPES
The first distinction to be made is that between atomic and aggregate datatypes.
[Definition: ] Atomic datatypes are those having values which are intrinsically indivisible.
[Definition: ] Aggregate datatypes are those having values which can be decomposed into two or
more component values.
For example, a date that is represented as a single character string could be the value of an atomic date
datatype; while another date represented as separate "month", "day" and "year" elements would be the value
of an aggregate date datatype. Not surprisingly, the distinction is analogous to that between an XML element
whose content model is #PCDATA and one with element content.
As discussed above, this specification focuses mainly on atomic datatypes. Later versions will address
aggregate datatypes in more detail. Note that the XML attribute types [IDREFS], [ENTITIES] and
[NMTOKENS] can be thought of as aggregate (list) types.
A datatype which is atomic in this specification need not be an "atomic" datatype in any programming
language used to implement this specification.

2.6.2 PRI MI TI VE VS. GENERATED DATATYPES
[Definition: ] Primitive datatypes are those that are not defined in terms of other datatypes; they
exist ab initio.
[Definition: ] Generated datatypes are those that are defined in terms of other datatypes.
For example, a [number] is a well defined mathematical concept that cannot be defined in terms of other
datatypes while a [date] is a special case of the more general datatype [dateTime].
The datatypes defined by this specification fall into both the primitive and the generated categories. It is felt
that a judiciously chosen set of primitive datatypes will serve the widest possible audience by providing a set
of convenient datatypes that can be used as is, as well as providing a rich enough base from which the
variety of datatypes needed by schema designers can be generated.
A datatype which is primitive in this specification need not be a "primitive" datatype in any programming

120 de 137

2.6.2.1 BASE TYPE
[Definition: ] Every generated datatype is defined in terms of an existing datatype, referred to as the base
type. Base types may be either primitive or generated.
In the example above, [date] is referred to as a subtype of the base type [dateTime]. The value space of a
subtype is a subset of the value space of the base type.

2.6.3 BUI LT- I N VS. USER- GENERATED DATATYPES
[Definition: ] Built-in datatypes are those which are entirely defined in this specification, and may
be either primitive or generated;
[Definition: ] User-generated datatypes are those generated datatypes whose base types are built-
in datatypes or user-generated datatypes and are defined by individual schema designers by giving
values to constraining facets.
Conceptually there is no difference between the built-in generated datatypes included in this specification and
the user-generated datatypes which will be created by individual schema designers. The built-in generated
datatypes are those which are believed to be so common that if they were not defined in this specification
many schema designers would end up reinventing them. Furthermore, including these generated datatypes in
this specification serves to demonstrate the mechanics and utility of the datatype generation facilities of this
specification.
A datatype which is built-in in this specification need not be a "built-in" datatype in any programming

3. BUI LT- I N DATATYPES
Issue (nulls): A future revision of this specification will provide a general mechanism for
specifying the difference between "null" and "not present" for all datatypes. Exactly what
that mechanism will be is an open issue at this point.

3.1 NAMESPACE CONSI DERATI ONS
The built-in datatypes defined by this specification are designed so that systems other than XML Schema may
be able to use them. To facilitate such usage, the built-in datatypes in this specification come from the XML
Datatype namespace, the namespace defined by this specification. This applies to both built-in primitive and
built-in generated datatypes.
NOTE: The exact URLs for the namespace(s) defined by this W3C specification is still an
open issue. This issue has been raised with the XML Coordination Group (issue 1999-0201-
07 Standardizing W3C namespace URIs) for general coordination and resolution.
Each user-generated datatype is also associated with a unique namespace. However, user-generated
datatypes do not come from the XML Datatype namespace; rather, they come from the namespace of the
schema in which they are defined. Note that associating a namespace with a user-generated datatype is not a
general purpose extensibility mechanism and does not apply to primitive datatypes. Suppose a schema author
wanted to introduce a new set of primitive datatypes, say a core set of mathematical datatypes not based on
the Number datatype defined as a built-in primitive by this specification. Such a schema author might try to
define those datatypes, associate a unique namespace with them and expect schema processors to
understand them. Unfortunately, such a scenario would not work. Each such datatype would need specialized
validation code and there are still many unresolved issues regarding standard mechanisms for sharing such
code.
As described in more detail in [User-generated datatypes], each user-generated datatype must be defined
in terms of a base type included in this specification or a user-generated datatype by assigning facets which
serve to constrain the value set of the user-generated datatype to a subset of the base type. Such a
mechanism works because all schema processors are required to be able to validate datatypes defined by
subsetting the value space of a datatype included in this specification.

121 de 137

3.2 PRI MI TI VE DATATYPES
The primitive datatypes are described below. For each primitive datatype we discuss the fundamental facets,
if any, and the constraining facets, if any.

3.2.1 I D
This is the ID datatype from [XML]. It applies only to attribute values. ID has no fundamental or constraining
facets.
Validity Constraint: ID
Values of type [ID] must match the Name production. A name must not appear more than once in an XML
document as a value of this type; i.e., ID values must uniquely identify the elements which bear them.
Ed. Note: There are several situations in which we need better reference mechanisms than
those provided by ID and IDREF/IDREFS. For example, it would be desirable to extend IDs
and IDREFs to be typed and scoped to better represent primary key/foreign key
relationships in a database. XSL has recently introduced the concept of xsl:key and
xsl:keyref whereby a single property of an element can be used as a key. We need such a
mechanism for XML as a whole and it would be nice if this were extended to support multi-
part keys.

3.2.2 I DREF
This is the IDREF datatype from [XML]. It applies only to attribute values. IDREF has no fundamental or
constraining facets.
Validity Constraint: IDREF
Values of type IDREF must match the Name production; each Name must match the value of an ID attribute
on some element in the XML document; i.e. IDREF values must match the value of some ID attribute.

3.2.3 I DREFS
This is the IDREFS datatype from [XML]. It applies only to attribute values. IDREFS has no fundamental or
Validity Constraint: IDREFS
Values of type IDREFS must match Names; each Name must match the value of an ID attribute on some
element in the XML document; i.e. IDREF values must match the value of some ID attribute.

3.2.4 ENTI TY
This is the ENTITY datatype from [XML]. It applies only to attribute values. ENTITY has no fundamental or
Validity Constraint: Entity Name
Values of type ENTITY must match the Name production; each Name must match the name of an unparsed
entity declared in the schema.

3.2.5 ENTI TI ES
This is the ENTITIES datatype from [XML]. It applies only to attribute values. ENTITIES has no fundamental
or constraining facets.
Validity Constraint: Entity Names

122 de 137

Values of type ENTITIES must match the Names production; each Name must match the name of an
unparsed entity declared in the schema.

3.2.6 NMTOKEN
This is the NMTOKEN datatype from [XML]. It restricts the contents to a valid XML name. NMTOKEN applies
only to attribute values and has no fundamental or constraining facets.
Validity Constraint: Name Token
Values of type NMTOKEN must match the Nmtoken production; values of type NMTOKENS must match
Nmtokens.
Issue (nmtoken-primitive-or-generated): should NMTOKEN be defined as a primitive
(as above) or as a subtype of [string] with a regular expression facet such as "[a-zA-Z0-
9_-]+" (or whatever the regular expression actually should be to match the Nmtoken
production)? A similar issue also applies to all of the XML attribute types, [ID], [IDREF],
[IDREFS], [ENTITY], [ENTITIES] and [NOTATION].

3.2.7 NMTOKENS
This is the NMTOKENS datatype from [XML]. It restricts the contents to a list of valid XML names. NMTOKENS
applies only to attribute values and has no fundamental or constraining facets.
Validity Constraint: Name Tokens
Values of type NMTOKENS must match the Nmtokens production.

3.2.8 NOTATI ON
This is the NOTATION datatype from [XML]. NOTATION has no fundamental or constraining facets.
Validity Constraint: Notation Attributes
Values of this type must match one of the notation names included in the declaration; all notation names in
the declaration must be declared.

3.2.9 STRI NG
[Definition: ] The string datatype represents character strings in XML. The value space of the string datatype
is the set of finite sequences of UCS characters ([ISO 10646] and [Unicode]). A UCS character (or just
character, for short) is an atomic unit of communication; it is not further specified except to note that every
UCS character has a corresponding UCS code point, which is an integer.

The string datatype has an optional constraining facet called [Lexical representation] The value of this
facet is either a picture or a regular expression. Picture types are discussed in Appendix [Pictures] and
regular expression constraints are discussed in Appendix [Regular Expressions]. If this facet is not present,
there is no restriction on the lexical representation.
Issue (picture-or-regex): Should the values of the [Lexical representation] facet be
pictures, regexs, both or some other mechanism?

3.2.9.2 LENGTH
The string datatype has an optional constraining facet called length. If length is specified we have a fixed
length character string. If length is not specified we have a variable length character string.

123 de 137

3.2.9.3 MAXI MUM LENGTH
The string datatype has an optional constraining facet called maxlength. If maxlength is specified for a
variable length string it represents an upper bound of the length of the string. Both length and maxlength
cannot be defined for the same datatype. The absolute maximum length of variable length character string
depends on the XML parser implementation.

3.2.9.4 MAXI MUM AND MI NI MUM VALUES
The string datatype also has the following constraining facets:
maxInclusive
maxExclusive
minInclusive
minExclusive
Clearly, the effect of these constraining facets depends on the collating sequence used to define the order
property for strings.
Ed. Note: The issue of collating sequences for strings is complex. It will be discussed in
detail in a subsequent version of this specification.

3.2.10 BOOLEAN
[Definition: ] The boolean datatype has the value space required to support the mathematical concept of
binary-valued logic: {true, false}.
Issue (three-valued-logic): Do we need to add a third value "unknown" to the value
space to support three-valued logic? SQL supports this. Will the general mechanism for
"nulls" to be defined in a future revision handle this case?

An instance of a datatype that is defined as boolean can have the following legal lexical values {0, 1, true,
false, yes, no}. If a lexical representation facet is not present in the datatype definition then all these lexical
values are allowed. A lexical representation facet can be added to the datatype definition to restrict the lexical
values to a subset of the above.

3.2.11 NUMBER
[Definition: ] The number datatype is the standard mathematical concept of number, including the integers,
reals, rationals, etc.
Number has the following constraining facets:
maxInclusive
maxExclusive
minInclusive
minExclusive
Ed. Note: The motivation for the number datatype was to allow the user to specify a value
that could take any legal lexical representation for a numeric quantity. This turns out to be
problematic, however, due to the large number of extant representations some of which

124 de 137

cannot be distinguished without extra information. Having to define a lexical representation
facet for number seems to defeat its purpose and, thus, the number datatype may be
removed from this specification.

3.2.12 DATETI ME
[Definition: ] The dateTime datatype represents a combination of date and time values as defined [SQL] and
in [ISO 8601] encoded as a single string. An optional facet specifies the lexical representation. If this is not
specified, all lexical representation formats conforming to [ISO 8601] Section 5 and [SQL] are acceptable.
Issue (non-gregorian-dates): Both standards are limited to Gregorian dates. As an
internalization issue, do we want support for non-gregorian dates? This issue also applies to
[date], [time] and [timePeriod].

If this facet is specified its value must correspond to a legal representation for combinations of dates and
times as defined in [SQL] and sections 5.1 and 5.4 of [ISO 8601].
Issue (dateTime-lexical-representation): We need to spell out the various SQL and ISO
8601 representations (e.g., CCYYMMDD and CCYY-MM-DD, etc.) in detail here, or in a (non-
normative) appendix. We may also want to support additional formats e.g. neither SQL or
ISO 8601 seems to support the 12/25/1999 format for date. A lexical representation for
dateTime as a collection of elements may also be desirable. This issue also applies to
[date], [time] and [timePeriod].

3.2.13 BI NARY
[Definition: ] The binary datatype represents strings (blobs) of binary data. It has two fundamental facets.
The optional length facet specifies the length of the data. If the length is not specified the default is unlimited
length. The optional "encoding" facet specifies the encoding which may be "hex" for hexadecimal digits or
"base64" for MIME style Base64 data.

3.2.14 URI
[Definition: ] The uri datatype represents a Universal Resource Identifier (URI) Reference as defined in [RFC
2396]. It has no fundamental or constraining facets.
Issue (uri-scheme-facet): should we have a facet to allow a limitation to a specific
scheme? It might be useful to able to say that something was not only a URI, but that it
was a "mailto" and not a "http://...".

3.3 GENERATED DATATYPES
This section gives conceptual definitions for all built-in generated datatypes defined by this specification,
including a description of the facets which apply to each datatype. The concrete syntax used to define
generated datatypes (whether built-in or user-generated) is given in section [User-generated datatypes]
and the complete definitions of the built-in generated datatypes (written in that concrete syntax) are provided
in Appendix [Built-in Generated Datatype Definitions (normative)].

3.3.1 I NTEGER
[Definition: ] The integer datatype corresponds to the standard mathematical concept of integer numbers.
The value space of the integer datatype is the infinite set {-,...,-2,-1,0,1,2,...,} although computer
implementations restrict this to a finite set. The basetype of integer is [number].
Integer has the following constraining facets:
maxInclusive

125 de 137

maxExclusive
minInclusive
minExclusive

If this optional required facet is not specified, standard integer representations are acceptable. These consist
of a string of digits with an optional sign or optional parentheses to indicate a negative number. Optional
commas may appear after every three digits. For example: -1, 12678967543233, (100,000).
This facet must be specified if other lexical representations are desired such as the European format that
allows periods after every three digits.

3.3.2 DECI MAL
[Definition: ] The decimal datatype restricts allowable values to numbers with an exact fractional part. The
basetype of decimal is [number].
Decimal has the following required fundamental facets:
precision: the total number of digits in the number.
scale: the number of digits after the decimal point. Must be less than or equal to precision.
Decimal has the following constraining facets:
maxInclusive
maxExclusive
minInclusive
minExclusive

If this optional required facet is not specified, standard decimal representations are acceptable. These consist
of a string of digits separated by a period as a decimal indicator, in accordance with the scale and precision
facets, with an optional sign or optional parentheses to indicate a negative number. Optional commas may
appear after every three digits. For example: -1.23, 12678967.543233, (100,000.00).
This facet must be specified if other lexical representations are desired such as the European format that uses
a comma instead of a period as the decimal indicator.
3.3.3 REAL
[Definition: ] The real datatype is a computational approximation to the standard mathematical concept of
real numbers. These are often called floating point numbers. The basetype of real is [number].
Real has the following constraining facets:
maxInclusive
maxExclusive
minInclusive
minExclusive

126 de 137

Real values have a single standard lexical representation consisting of a mantissa followed by the character
"E" followed by an exponent. The exponent must be an integer with optional sign without parentheses or
commas. The mantissa must be a decimal number with optional sign without parentheses or commas. For
example: -1E4, 1267.43233E12, 12.78E-2.

3.3.4 DATE
[Definition: ] The date datatype represents a date value as defined in [ISO 8601] encoded as a single string.
The basetype of date is [dateTime]. An optional fundamental facet specifies the lexical format. If this is not
specified, all lexical representation formats conforming to [ISO 8601] Section 5.2 and [SQL] are acceptable.
For example, 1985-04-12, 19850412.
Issue (other-date-representations): Both ISO and SQL allow only the minus sign, "-",
as separator? Do we want to allow other separators such as the solidus, "/" or colon, ":" ?
We also need to discuss the aggregate representation for dates.

This optional facet can be used to restrict the allowed lexical representations. Its value must correspond to a
legal representation for dates as defined Section 5.2 of [ISO 8601] or [SQL].

3.3.5 TI ME
[Definition: ] The time datatype represents a time value as defined in [ISO 8601] encoded as a single string.
The basetype of date is [dateTime]. An optional fundamental facet specifies the lexical format. If this is not
specified, all lexical representation formats conforming to [ISO 8601] Section 5.3 and [SQL] are acceptable.
For example, 23:20:50, 232050.

This optional facet can be used to restrict the allowed lexical representations. Its value must correspond to a
legal representation for time as defined Section 5.3 of [ISO 8601] or [SQL].
3.3.6 TI MEPERI OD
[Definition: ] The timePeriod datatype represents a period of time as defined in [ISO 8601] encoded as a
single string. The basetype of date is [dateTime]. A timePeriod is one of:
a duration of time with a specific start and end. For example, 19990412T232050/19990415T021000,
in [ISO 8601] syntax, where the start and end are separated by the solidus, "/", and the date and
time by the letter "T".
a duration of time without a specified start and end (e.g., 1 second, 3 months) This corresponds to
the [SQL] datatype "interval". For example, 2001-01-05-12.00.00.0000 in SQL syntax.
a duration of time with a specific start but not a specific end. For
example,19990412T232050/P1Y3M15D12H30M in [ISO 8601] syntax.
a duration of time with a specific end but not a specific start, For example,
P1Y3M15D12H30M/19990415T021000 in [ISO 8601] syntax.
The [ISO 8601] formats need to be extended to support:
A minus sign immediately following the "P" to indicate negative periods.
An optional fundamental facet specifies the lexical format. If this is not specified, all lexical representation
formats conforming to [ISO 8601] Section 5.5 and [SQL] are acceptable.


127 de 137

If this facet is specified its value must correspond to a legal representation for time periods as defined in
section 5.5 of [ISO 8601] or [SQL].

4. USER- GENERATED DATATYPES
A user-generated datatype can be defined from a built-in datatype by adding optional constraining facets. For
example, someone may want to define a datatype called heightInInches from the built-in datatype integer by
supplying maxInclusive and minInclusive facets. In this case, heightInInches is the name of the new user-
generated datatype, integer is its base type and maxInclusive and minInclusive are the constraining facets.
<datatype name="heightInInches">
<basetype name="real" URI="http://www.w3.org/xmlschemas/datatypes" />
<minInclusive>
0.0
</minInclusive>
<maxInclusive>
120.0
</maxInclusive>
</datatype>
Ed. Note: The abstract syntax proposed here (and the productions) are preliminary as they
allow datatype definitions which are logically inconsistent (e.g., they allow numeric facets on
non-numeric datatypes). This will be corrected in future drafts, as the XML Schema
language comes to allow the specification of tighter constraints.
Ed. Note: This section needs more explanatory text describing the productions and their
relationship to the conceptual framework described in sections [Type System] and [Built-
in datatypes].
Datatype definitions
[1] datatypeDefn ::= NCName basetype facets* [ Constraint: Unique datatype definitions ]
[2] basetype ::= datatypename
[3] facets ::= ordered | unordered [ Constraint: Appropriate facets ]
The following is the definition for a possible built-in generated datatype "currency". Such a datatype definition
could appear in the schema which defines datatypes for XML Schemas and shows that a generated datatype
can have the same value space as its basetype, which might mean that it is just an alias or renaming of the
basetype. In this case, the specification would probably also define some "semantics" for currency which went
beyond those of decimal.
<datatype name="currency">
<basetype name="dt:decimal"/>
</datatype>
Constraint: Unique datatype definitions
The name of the datatype being defined must be unique among the datatypes defined in the containing
schema.
Constraint: Appropriate facets
If the value space of the basetype is ordered, then only ordered facets may appear in a datatype definition.
Datatype names
[4] datatypename ::= builtinname | usergenname
[5] builtinname ::= ID | IDREF | IDREFS |
NMTOKEN | NMTOKENS |
ENTITY | ENTITIES |
string | uri | binary |
number | integer | real | decimal |
dateTime | date | time | timePeriod

128 de 137

[6] usergenname ::= NCName schemaRef [ Constraint: Datatype name ]
NOTE: The production labeled datatypename above is not to be confused with that labeled
datatypeName in Section 3.3.1 of [Structural Schemas].
Constraint: Datatype name
The name specified must be the name of a datatype defined in the schema in which the user-generated
datatype is defined.
Facets
[7] ordered ::= bounds | numeric
[8] unordered ::= lexicalRepresentation | enumeration | length | maxLength
Ordered facets
[9] bounds ::= (minInclusive | maxInclusive)? (minExclusive | maxExclusive)?
[10] maxInclusive ::= literalValue [ Constraint: Literal type ]
[11] minInclusive ::= literalValue [ Constraint: Literal type ]
[12] minExclusive ::= literalValue [ Constraint: Literal type ]
[13] maxExclusive ::= literalValue [ Constraint: Literal type ]
Constraint: Literal type
The literal value specified must be of the same type as the basetype in the datatype definition in which this
facet appears.
Numeric facets
[14] numeric ::= precision | scale
[15] precision ::= integerLiteral
[16] scale ::= integerLiteral
The following is the definition for a user-generated datatype which could be used to represent monetary
amounts for use in a financial management application which does not allow figures above $1M and allows
only whole cents. This definition would appear in a schema authored by an end-user (i.e., not in the schema
for schemas) and shows how to define a datatype by specifying facet values which constrain the range of the
basetype in a manner specific to the basetype. This is different than specifying max/min values as discussed
before.
This type could just as well have been defined with the potential built-in generated type "currency", defined
above, as its basetype,
<datatype name="amount">
<basetype name="decimal" URI="http://www.w3.org/xmlschemas/datatypes" />
<precision>
8
</precision>
<scale>
2
</scale>
</datatype>
Unordered facets
[17] length ::= integerLiteral
[18] maxLength ::= integerLiteral
[19] enumeration ::= literal+
[20] lexicalRepresentation ::= lexical+
[21] lexical ::= lexicalSpec [ Constraint: Lexical specification ]

129 de 137

Constraint: Lexical specification
The lexical specification must be of the "correct" kind, i.e., a dateTime lexical representation for datatypes
generated from [dateTime] etc.
The following example is a definition for a user-generated datatype which limits the possible lexical
representations of dates to the two main forms found in [ISO 8601] section 5.2.1.1. This datatype definition
would appear in a schema authored by an end-user and shows how to define a datatype by restricting the
lexical form of its literals. The example also shows how this datatype would be used in an element definition.
<datatype name="myDate">
<basetype name="date" URI="http://www.w3.org/xmlschemas/datatypes" />
<lexicalRepresenation>
<lexical>
CCYYMMDD
</lexical>
<lexical>
CCYY-MM-DD
</lexical>
</lexicalRepresenation>
</datatype>

<elementType name="shippingDate">
<datatypeRef name="myDate">
</elementType>
Given the definitions above, the following might occur in an instance document.
...
<shippingDate>19990510</shippingDate>
...
<shippingDate>1999-05-10</shippingDate>
Both of the above shipping dates refer to "abstract" date of May 10, 1999
The following example is a datatype definition for a user-generated datatype which limits the possible literal
values of dates to the four US holidays enumerated. This datatype definition would appear in a schema
authored by an end-user and shows how to define a datatype by enumerating the values in its value space.
The enumerated values must be type-valid literals for the basetype.
<datatype name="holidays">
<basetype name="date" URI="http://www.w3.org/xmlschemas/datatypes" />
<enumeration>
<literal>
-0101 
</literal>
<literal>
-0704 
</literal>
<literal>
-1125 
</literal>
<literal>
-1225 
</literal>
</enumeration>
</datatype>
Literals
[22] literal ::= literalValue
[23] literalValue ::= stringLiteral | numericLiteral | dateTimeLiteral | uriLiteral
[24] stringLiteral ::= (see [string])
[25] numericLiteral ::= integerLiteral | realLiteral | decimalLiteral
[26] integerLiteral ::= (see [integer])
[27] realLiteral ::= see [real]
[28] decimalLiteral ::= see [decimal]

130 de 137
[29] dateTimeLiteral ::= (see [dateTime])
[30] uriLiteral ::= (see [uri])
Issue (definition-overriding): should it be possible to specify a value for a non-
fundamental facet on an element or attribute of a given datatype in an instance document
or in an element or attribute definition in a schema (see Section 3.4.4 of [Structural
Schemas])? If so, what syntax should be used? This needs to be coordinated with the
structural schema editorial team.
5. CONFORMANCE
The XML specification [XML] defines two levels of conformance. Well-formed documents conform to valid XML
syntax but may or may not obey the constraints defined by a DTD. Valid XML documents conform to the
structure laid down in a DTD. Thus, if a DTD defines an attribute as an ID, instances of XML documents
conforming to the DTD can only be valid if the values of such attributes are valid XML names and are unique
in the document. By introducing additional datatypes to XML, this specification extends the notion of validity
in the sense that values defined to have a certain datatype in the schema must conform to the lexical
representations allowed for that datatype. It also needs to be said that that is all that is expected of an XML
processor. There are no expressions on datatypes. Neither are there operations on datatypes.
In some cases, datatypes will not be specified in the schema but will be specified in XML documents. In other
cases, datatypes in the documents will be specialized versions of datatypes specified for the same component
in the schema. Validating XML processors should be able to validate the format of values in XML documents in
these cases as well.

APPENDICES

A. SCHEMA FOR DATATYPE DEFI NI TI ONS ( NORMATI VE)

<?xml version='1.0'?>
<!DOCTYPE schema PUBLIC '-//W3C//DTD XSDL 19990506//EN'
'http://www.w3.org/1999/05/06-xsdl/WD-xsdl.dtd'>

<schema xmlns='http://www.w3.org/TR/1999/WD-xdtl-19990506.xsd'
name='http://www.w3.org/TR/1999/WD-xdtl-19990506.xsd'
version='0.1'>
<modelGroup name="ordered">
<choice>
<modelGroupRef name="bounds"/>
<modelGroupRef name="numeric"/>
</choice>
</modelGroup>
<modelGroup name="bounds">
<choice>
<sequence>
<elementTypeRef name="minInclusive" minOccur="0" maxOccur="1"/>
<elementTypeRef name="maxInclusive" minOccur="0" maxOccur="1"/>
</sequence>
<sequence>
<elementTypeRef name="minExclusive" minOccur="0" maxOccur="1"/>
<elementTypeRef name="maxExclusive" minOccur="0" maxOccur="1"/>
</sequence>
</choice>
</modelGroup>
<modelGroup name="numeric">
<choice>
<elementTypeRef name="precision"/>
<elementTypeRef name="scale"/>
</choice>
</modelGroup>
<modelGroup name="unordered">
<choice>
<modelGroupRef name="lexicalRepresentation"/>
<modelGroupRef name="enumeration"/>
<modelGroupRef name="length"/>
<modelGroupRef name="maxLength"/>
</choice>

131 de 137

</modelGroup>

<elementType name="datatype">
<sequence>
<elementTypeRef name="basetype"/>
<choice minOccur="0" maxOccur="*">
<modelGroupRef name="ordered"/>
<modelGroupRef name="unordered"/>
</choice>
</sequence>
<attrDecl name="name" required="true">
<datatypeRef name="NMTOKEN"/>
</attrDecl>
<attrDecl name="export">
<datatypeRef name="boolean">
<default>true</default>
</datatype>
</attrDecl>
</elementType>
<elementType name="basetype">
<empty/>
<attrDecl name="name" required="true">
</attrDecl>
<attrDecl name="schemaAbbrev">
</attrDecl>
<attrDecl name="schemaName">
<datatypeRef name="uri"/>
</attrDecl>
</elementType>
<elementType name="maxExclusive">
<datatypeRef name="string"/> 
</elementType>
<elementType name="minExclusive">
</elementType>
<elementType name="maxInclusive">
</elementType>
<elementType name="minInclusive">
</elementType>
<elementType name="precision">
<datatypeRef name="integer"/>
</elementType>
<elementType name="scale">
</elementType>
<elementType name="length">
</elementType>
<elementType name="maxLength">
</elementType>
<elementType name="enumeration">
<sequence minOccur="1" maxOccur="*">
<elementTypeRef name="literal"/>
</sequence>
</elementType>
<elementType name="literal">
</elementType>
<elementType name="lexicalRepresentation">
<sequence minOccur="1" maxOccur="*">
<elementTypeRef name="lexical"/>
</sequence>
</elementType>
<elementType name="lexical">

132 de 137

</elementType>
</schema>

B. DTD FOR DATATYPE DEFINITIONS (NORMATIVE)

<!ENTITY % numeric "precision | scale">
<!ENTITY % bounds "((minInclusive | minExclusive)?,
(maxInclusive | maxExclusive)?)">
<!ENTITY % ordered "%bounds; | %numeric;">
<!ENTITY % unordered "lexicalRepresentation | enumeration
| length | maxLength">

<!ELEMENT datatype (basetype, (%ordered; | %unordered;)*)>
<!ATTLIST datatype
name NMTOKEN #REQUIRED
export (true|false) "true">

<!ELEMENT basetype EMPTY>
<!ATTLIST basetype
name NMTOKEN #REQUIRED
schemaAbbrev NMTOKEN #IMPLIED
schemaName CDATA #IMPLIED>

<!ELEMENT maxExclusive (#PCDATA)>
<!ELEMENT minExclusive (#PCDATA)>
<!ELEMENT maxInclusive (#PCDATA)>
<!ELEMENT minInclusive (#PCDATA)>

<!ELEMENT precision (#PCDATA)>
<!ELEMENT scale (#PCDATA)>

<!ELEMENT length (#PCDATA)>
<!ELEMENT maxLength (#PCDATA)>
<!ELEMENT enumeration (literal)+>
<!ELEMENT literal (#PCDATA)>
<!ELEMENT lexicalRepresentation (lexical)+>
<!ELEMENT lexical (#PCDATA)>

C. BUILT-IN GENERATED DATATYPE DEFINITIONS (NORMATIVE)
This section gives the datatype definitions for all built-in generated datatypes. These definitions are to appear
in the "schema for schemas" and not in schema instances written by end-users.
Ed. Note: this section needs to be expanded to include all built-in generated datatypes
defined in [Generated datatypes]
<datatype name="date">
<basetype name="dateTime" URI="http://www.w3.org/xmlschemas/datatypes" />
<lexicalRepresentation>

<lexical>
CCYYMMDD 
</lexical>
<lexical>
CCYY-MM-DD
</lexical>

<lexical>
CCYY-MM 
</lexical>
<lexical>
CCYY 
</lexical>

133 de 137

<lexical>
CC 
</lexical>

<lexical>
YYMMDD 
</lexical>
<lexical>
YY-MM-DD 
</lexical>
<lexical>
-YYMM 
</lexical>
<lexical>
-YY-MM 
</lexical>
<lexical>
-YY 
</lexical>
<lexical>
--MMDD 
</lexical>
<lexical>
--MM-DD 
</lexical>
<lexical>
--MM 
</lexical>
<lexical>
---DD 
</lexical>

<lexical>
CCYYDDD 
</lexical>
<lexical>
CCYY-DDD 
</lexical>

<lexical>
YYDDD 
</lexical>
<lexical>
YY-DDD 
</lexical>
<lexical>
-DDD 
</lexical>

<lexical>
CCYYWwwD 
</lexical>
<lexical>
CCYY-Www-D
</lexical>

<lexical>
CCYYWww 
</lexical>
<lexical>
CCYY-Www 
</lexical>

<lexical>
YYWwwD 
</lexical>
<lexical>
YY-Www-D 

134 de 137

</lexical>
<lexical>
YYWww 
</lexical>
<lexical>
YY-Www 
</lexical>
<lexical>
-YWwwD 
</lexical>
<lexical>
-Y-Www-D 
</lexical>
<lexical>
-WwwD 
</lexical>
<lexical>
-Www-D 
</lexical>
<lexical>
-Www 
</lexical>
<lexical>
-W-D 
</lexical>
<lexical>
---D 
</lexical>
</lexicalRepresentation>
</datatype>

D. PICTURES
"Pictures", similar to those in [COBOL] picture clauses, can be used to constrain the format of strings and in
some cases control their conversion to numbers. A picture is an alphanumeric string consisting of character
symbols. Each symbol, which is usually one character but may be two characters, is a placeholder that stands
for a set of characters. For example, the picture "A" stands for a single alphabetic character.
The following is a list of picture symbols and their meanings.
A
A single alphabetic character.
B
A single blank character.
E
The character E, used to indicate floating point numbers.
S
The leftmost character of a picture indicating a signed number. The characters "+" or "-" may appear in the S
position.
V
An implied decimal sign. The input 1234 validated by a picture 99V99 is converted into 12.34.
X
Any character.
Z
The leftmost leading numeric character that can be replaced by a space character when the content of that
content position is a zero.
9
Any numeric character.
1
Any boolean character (0 or 1).
0,/,-,., and ,
represent themselves.
cs
A placeholder for an appropriate currency symbol.
Here are some examples of picture constraints
$123,45.90 satisfies picture $999,99.99
$123,45.90 satisfies picture XXXX,XX.XX

135 de 137

123-45-5678 satisfies picture 999-99-9999 (Social Security Number)
24E80 satisfies picture 99E99 (floating point)
23.45 satisfies picture 99.99
2345 satisfies picture 99V99 (translates to 23.45)

E. REGULAR EXPRESSIONS
Ed. Note: The following description of regular expressions is copied (with slight
modification) by permission from the documentation of the [Perl] programming language.
Issue (perl-regex): Should the final recommendation use Perl's regular expression
"extensions"?
[Definition: ] Regular expressions, similar to those in [Perl], can be used to constrain the format of strings.
A regular expression is an alphanumeric string consisting of character symbols. Each symbol, which is usually
one character but may be two characters, is a placeholder that stands for a set of characters.
Any single character matches itself, unless it is a metacharacter with a special meaning described here or
above. You can cause characters that normally function as metacharacters to be interpreted literally by
prefixing them with a "\" (e.g., "\." matches a ".", not any character; "\\" matches a "\"). A series of
characters matches that series of characters in the target string, so the pattern blurfl would match "blurfl" in
the target string.
You can specify a character class, by enclosing a list of characters in [], which will match any one character
from the list. If the first character after the "[" is "^", the class matches any character not in the list. Within a
list, the "-" character is used to specify a range, so that a-z represents all characters between "a" and "z",
inclusive. If you want "-" itself to be a member of a class, put it at the start or end of the list, or escape it
with a backslash. (The following all specify the same class of three characters: [-az], [az-], and [a\-z]. All are
different from [a-z], which specifies a class containing twenty-six characters.)
Certain characters as used as metacharacters. The following list contains all of the metacharacters and their
meanings.
\
Quote the next metacharacter
^
Match the beginning of the line
.
Match any character (except newline)
$
Match the end of the line (or before newline at the end)
|
Alternation
()
Grouping
[]
Character class
Within a regular expression, the following standard quantifiers are recognized:
*
Match 0 or more times
+
Match 1 or more times
?
Match 1 or 0 times
{n}
Match exactly n times
{n,}
Match at least n times
{n,m}
Match at least n but not more than m times
The following character sequences also have special meaning within a regular expression.
\t
tab
\n
newline
\r
return

136 de 137

\033
octal char 003
\x1B
hex char 1B
\w
Match a "word" character (alphanumeric plus "_")
\W
Match a non-word character
\s
Match a whitespace character
\S
Match a non-whitespace character
\d
Match a digit character
\D
Match a non-digit character
Ed. Note: we should probably define XML-specific character sequences for things like
Nmtoken, Name, etc., as well as ones for the character classes listed in XML 1.0 Appendix
B. Character Classes
Regular expressions may also contain the following zero-width assertions:
\b
Match a word boundary
\B
Match a non-(word boundary)
A word boundary (\b) is defined as a spot between two characters that has a \w on one side of it and a \W on
the other side of it (in either order), counting the imaginary characters off the beginning and end of the string
as matching a \W.
555-1212 is matched by \d{3}-\d{4} (phone number)
888-555-1212 is matched by (\d{3}-)?\d{3}-\d{4} (phone number with optional area code)
$123,45.90 is matched by \$\d{3},\d{2}\.\d{2}
123-45-5678 is matched by \d{3}-?\d{2}-?\d{4} (Social Security Number)

F. REFERENCES

COBOL
COBOL Standard. See http://www.dkuug.dk/jtc1/sc22/wg4/
ISO 10646
Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane.
[Geneva]: International Organization for Standardization, 1993 (plus amendments AM 1 through AM 7).
ISO 11404
Language-independent Datatypes. Available from http://web.ansi.org/public/catalog/cat_top.html
ISO 8601
Representations of dates and times. See http://www.iso.ch/markete/8601.pdf
Available from http://www.w3.org/TR/1998/WD-xsl-19981216
Namespaces in XML
Namespaces in XML, Tim Bray et al. W3C, 1998 Available at: http://www.w3.org/TR/REC-xml-names
Perl
The Perl Programming Language. See http://www.perl.org
RDF Schema
RDF Schema Specification. See http://www.w3.org/TR/PR-rdf-schema
RFC 2396
Tim Berners-Lee, et. al. RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax.. 1998 Available at:
http://www.ietf.org/rfc/rfc2396.txt
SQL
SQL Standard. See http://www.jcc.com/SQLPages/jccs_sql.htm
Structural Schemas
XML Schema Part 1: Structures. Available at: http://www.w3.org/XML/Group/1999/05/06-xmlschema-1/
Unicode

137 de 137

The Unicode Consortium. The Unicode Standard, Version 2.0. Reading, Mass.: Addison-Wesley Developers Press,
1996.
XML
XML Standard. See http://www.w3.org/TR/REC-xml
XML Schema Requirements
XML Schema Requirements. Available at: http://www.w3.org/TR/NOTE-xml-schema-req
XSL
XSL Working Draft. See http://www.w3.org/TR/1998/WD-xsl-19981216

G. OPEN I SSUES

nulls
nmtoken-primitive-or-generated
picture-or-regex
three-valued-logic
non-gregorian-dates
dateTime-lexical-representation
uri-scheme-facet
other-date-representations
definition-overriding
perl-regex

Manual de XSL y XML PDF

Cargado por

Copyright:

Formatos disponibles

Manual de XSL y XML PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Manual de XSL y XML PDF

Cargado por

Copyright:

Formatos disponibles

1 de 137

16 de enero de 2001 www.coverlink.com Manual de XML/XSL

y slo funciona con Internet Explorer 5.0.

También podría gustarte