CURSO DE XLM PARTE 2

Extensible Markup Language (XML) 1.0

1. Introducción

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 aplicación" o una forma restringida de SGML, el Lenguaje Estándar Generalizado de Marcación [ISO 8879]. Por construcción, los documentos XML son documentos SGML conformados.

Los documentos XML están compuestos por unidades de almacenamiento llamadas entidades, que contienen tanto datos analizados como no analizados. Los datos analizados están compuestos de caracteres, algunos de los cuales, de la forma datos carácter, y otros de la forma marca. Las marcas codifican una descripción de la estructura de almacenamiento del documento y su estructura lógica. XML proporciona un mecanismo para imponer restricciones al almacenamiento y a la estructura lógica.

Se utiliza un módulo 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 módulo, llamado aplicación. Esta especificación describe el comportamiento requerido de un procesador XML en términos de cómo leer datos XML y la información que debe proporcionar a la aplicación.

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 participación activa de un Grupo Especial de Interés en XML (previamente conocido como Grupo de Trabajo SGML) también organizado en el W3C. Los miembros del Grupo de Trabajo XML se especifican en un apéndice. Dan Connolly sirvió como contacto entre el GT y el W3C.

Los objetivos de diseño 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 fácil la escritura de programas que procesen documentos XML.
5. El número de características opcionales en XML debe ser absolutamente mínima, idealmente cero.
6. Los documentos XML deben ser legibles por humanos y razonablemente claros.
7. El diseño de XML debe ser preparado rápidamente.
8. El diseño de XML debe ser formal y conciso.
9. Los documentos XML deben ser fácilmente creables.
10. La concisión en las marcas XML es de mínima importancia.

Esta especificación, junto con los estándares asociados (Unicode e ISO/IEC 10646 para caracteres, Internet RFC 1766 para identificación de lenguajes, ISO 639 para códigos de nombres de lenguajes, e ISO 3166 para códigos de nombres de países), proporciona toda la información necesaria para entender la Versión 1.0 de XML y construir programas de computador que los procesen.

Esta versión de la especificación puede ser distribuida libremente, siempre y cuando se mantengan intactos todos los textos y términos legales.

1.2 Terminología

La terminología utilizada para describir los documentos XML esta definida en el cuerpo de esta especificación. Los términos definidos en la siguiente lista son utilizados en la construcción de esas definiciones y en la descripción de las acciones del procesador XML:

poder

La conformación de documentos y los procesadores de XML pueden permitirlo, pero no requieren ser soportados tal y como se describen.

deber

La conformación de documentos y los procesadores de XML deben soportarlo tal y como se describe, de otro modo son erróneos.

error

Una violación de las reglas de esta especificación, los resultados están indefinidos. Los programas conformadores deberían 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 aplicación. Tras encontrar un error fatal, el procesador tiene que continuar procesando los datos para buscar otros posibles errores y debería de informar de los errores a la aplicación. Para soportar la corrección de errores, el procesador debería hacer que los datos no procesados del documento (con datos carácter y marcas) sean accesibles a la aplicación. Una vez que se detecta un error fatal, el procesador debe continuar el procesado normalmente (p.e. no debe continuar pasando los datos carácter e información acerca de la estructura lógica del documento a la aplicación).

opción 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.

restricción de validez

Una regla que se aplica a todo documento XML válido. Las violaciones de la restricción de validez son errores, y los procesadores validadores de XML deben, por opción de usuario, informar de ellas.

restricción de buena-formación

Una regla que se aplica a todo documento XML bien-formado. Las violaciones de la restricción buena-formación son errores fatales.

igualdad

(de cadenas de caracteres o nombres:) Dos cadenas de caracteres o nombres a comparar deben ser idénticos. Los caracteres con múltiples representaciones posibles en la norma ISO/IEC 10646 (p.e. los caracteres con formas precompuestas y los "base+diacritic") sólo son comparables si tienen la misma representación en ambas cadenas. Por opción de usuario, los procesadores pueden normalizar estos caracteres a alguna forma canónica (de cadenas de caracteres y reglas en la gramática:) Una cadena de caracteres es igual a una producción gramatical si pertenece al lenguaje generado por esa producción. (de contenido y modelos de contenido:) Un elemento es igual a su declaración cuando conforma las reglas descritas en la restricción de "Validez de Elemento".

por compatibilidad

Una característica de XML incluida únicamente para asegurar que XML permanece compatible con SGML.

por interoperatividad

Una recomendación no obligatoria incluida para incrementar las funcionalidades de los documentos XML que pueden ser procesados por la base instalada existente de procesador SGML que añadan 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 especificación. Un documento XML bien-formado puede además ser válido si cumple una serie de restricciones.

Todo documento XML posee una estructura lógica y una física. Físicamente, 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 "raíz" o entidad documento. Lógicamente, 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 explícitas. Las estructuras lógica y física 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-formación dadas en esta especificación.
3. Cada una de las entidades analizadas que se referencia directa o indirectamente en el documento está bien-formada.

Cumplir la producción document implica que:

1. Contiene uno o más elementos.
2. Hay exactamente un elemento, llamado raíz, o elemento documento, del cual ninguna parte aparece en el contenido de ningún otro elemento. Para el resto de elementos, si la etiqueta de comienzo está en el contenido de algún 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 raíz H en el documento, existe otro elemento P tal que H está contenido en P, pero no es el contenido de ningún 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 carácter. Un carácter es una unidad atómica 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 línea y los caracteres gráficos legales del estándar Unicode y de la norma ISO/IEC 10646. La utilización de "compatibilidad de caracteres", como se define en la sección 6.8 de [Unicode], no está contemplada.

Los mecanismos para codificar los códigos 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 señalar cual de las dos está en uso, o para definir otras codificaciones, se discutirá más abajo en la sección "4.3.3 Codificación de Caracteres en Entidades".

2.3 Construcciones Sintácticas Comunes

Esta sección define algunos símbolos utilizados en la gramática.

El símbolo S (espacio en blanco) está compuesto de uno o más caracteres espacio (#x20), retornos de carro, finales de línea o tabuladores.

Los caracteres se clasifican, por conveniencia, en letras, dígitos u otros caracteres. Las letras se componen de caracteres de base alfabética o silábica, seguidos de uno o más caracteres combinatorios, o caracteres ideográficos. 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 más caracteres de puntuación, y que continua con letras, dígitos, 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 estandarización en esta o futuras versiones de esta especificación.

Nota: El carácter dos puntos en los nombres XML está reservado para la experimentación con espacios de nombres. Se prevé que se estandarizará su significado en un futuro, en el que los documentos que utilicen este carácter con propósitos experimentales deberán ser actualizados. (No existe garantía de que se adopte el mecanismo de espacios de nombres para XML). En la práctica, esto significa que los autores no deberían utilizar los dos puntos en XML, excepto como parte de espacios de nombres experimentales. Sin embargo los procesadores XML deben aceptar este carácter en los Nombres.

Un "Nmtoken" (name token) es cualquier combinación de caracteres de nombre.

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 símbolo "SystemLiteral" puede ser analizado sin tomar en cuenta la presencia de marcas.

2.4 Datos Carácter y Marcas

El Texto consiste en datos carácter y marcas entremezcladas. Las Marcas toman la forma de etiquetas de comienzo, etiquetas de fin, etiquetas de elementos vacíos, 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 carácter del documento.

El carácter "ampersand" (&) y el paréntesis angular de apertura (<) pueden aparecer de forma literal sólo cuando se utilicen como delimitadores de marcas, o dentro de los comentarios, en instrucciones de procesamiento, o en secciones CDATA. También pueden utilizarse en los valores literales de entidad de una declaración de entidad interna; ver "4.3.2 Entidades Analizadas Bien-Formadas". Si son necesarios en cualquier otro punto, deben ser "escapados" mediante la utilización de referencias numéricas a caracteres, o mediante las cadenas "&amp;" y "&lt;" respectivamente. El paréntesis angular de cierre (>) puede ser representado utilizando la cadena "&gt;", y debe, por compatibilidad, ser "escapado" utilizando "&gt;" o la referencia a carácter cuando aparece como contenido de la cadena "]]>", siempre y cuando la cadena no marque el final de una sección CDATA.

En el contenido de los elementos, los datos carácter son cualquier cadena de caracteres que no contenga el delimitador de comienzo de marca. En las secciones CDATA, los datos carácter son aquellos que no se incluyan en el delimitador de fin de sección CDATA, "]]>".

Para permitir que los valores de los atributos puedan contener tanto las comillas simples como las dobles, el carácter apóstrofe o comilla simple (') puede ser representado como "&apos;", y el comilla doble (") como "&quot;".

2.5 Comentarios

Los Comentarios pueden aparecer en cualquier punto del documento, fuera del resto de marcas; además, pueden aparecer en la declaración de tipo de documento, en los lugares permitidos por la gramática. No son parte de los datos carácter del documento. Un procesador XML puede, pero no debe, permitir a la aplicación obtener el texto de los comentarios. Por compatibilidad, la cadena "--" (dos guiones) no puede aparecer dentro de un comentario.

Un ejemplo de comentario:

2.6 Instrucciones de Procesamiento

Las Instrucciones de Procesamiento (PIs) permiten a los documentos contener instrucciones para las aplicaciones.

Las PIs no son parte de los datos carácter del documento, pero deben ser pasadas a la aplicación. Las PIs empiezan con un destino (PITarget) utilizado para identificar a la aplicación a la que está dirigida dicha instrucción. Los nombres de destino "XML", "xml", y las combinaciones de mayúsculas y minúsculas a partir de éstas, están reservados para estandarización en esta o futuras versiones de esta especificación. El mecanismo de Notación XML puede ser utilizado para la declaración formal de destinos de PIs.

2.7 Secciones CDATA

Las secciones CDATA pueden aparecer allá donde pueden aparecer los datos carácter. Se utilizan para "escapar" bloques de texto que contengan caracteres que de otra forma se reconocerían como marcas. Las secciones CDATA comienzan por la cadena "<![CDATA[" y terminan con la cadena "]]>":

En una sección CDATA sólo la cadena CDEnd se reconoce como marca, por lo tanto, el paréntesis angular de apertura y el carácter "ampersand" pueden aparecer de forma literal, es decir, no necesitan (y no pueden) ser "escapados" mediante "&lt;" ni "&amp;". No se pueden anidar las secciones CDATA.

Veamos un ejemplo de sección CDATA, en el cual "<saludo>" y "</saludo>" son reconocidos como datos carácter, y no como marcas:

2.8 Prolog y Declaración de Tipo de Documento

Los documentos XML pueden, y deberían, comenzar con una declaración XML que especifica la versión de XML utilizada. Por ejemplo, el siguiente es un documento XML completo, bien-formado pero no válido:

y también lo es:

El número de versión "1.0" debería utilizarse para indicar la conformancia a esta versión de la especificación. Se produce un error si un documento utiliza el valor "1.0" y éste no conforma la especificación de esta versión. Es intención del Grupo de Trabajo XML el proveer de nuevos números versiones de esta especificación, pero no se asegura que habrán futuras versiones de XML. Dado que no se han regulado futuras versiones, esta construcción se ha permitido para posibilitar el reconocimiento automáticamente de la versión, si fuese necesario. Los procesadores deben indicar que existe un error si reciben un documento etiquetado con una versión que no soportan.

La función de las marcas en los documentos XML reside en describir su almacenamiento y estructura lógica, así como asociar pares atributo-valor con dicha estructura lógica. XML proporciona un mecanismo, la declaración de tipo de documento, para definir restricciones sobre las estructuras lógicas y para contemplar el uso de unidades de almacenamiento predefinidas. Un documento XML es válido si tiene asociada una declaración de tipo de documento y si el documento cumple las restricciones que allí se expresan.

La declaración de tipo documento debe aparecer antes que el primer elemento en el documento.

La declaración de tipo de documento XML, contiene o describe declaraciones de marcas que proporcionan una gramática para una clase de documentos. Esta gramática se conoce como definición de tipo de documento o DTD. La declaración 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 unión de ambos subconjuntos.

Una declaración de marcación es una declaración de tipo de elemento, una declaración de lista de atributos, una declaración de entidad, o una declaración de notación. Estas declaraciones pueden estar contenidas en su totalidad o en parte en las entidades parámetro, como se describe en las restricciones de buena-formación y validez. Para más información al respecto, ver la sección "4. Estructuras Físicas".

La declaración de marcas puede estar constituida totalmente o en parte de texto de reemplazo de entidades parámetro. Las reglas de producción que aparecerán en esta especificación para los no terminales individuales (elementdecl, AttlistDecl, etc.) describen las declaraciones después de que todas las entidades parámetro hayan sido incluidas.

Restricción de Validez: Tipo de Elemento Raíz
El Nombre (Name) en la declaración de tipo de documento debe ser igual al tipo de elemento del elemento raíz.

Restricción de Validez: Declaración Apropiada/Anidamiento de PEs
El texto de reemplazo de la entidad parámetro debe estar anidado apropiadamente dentro de la declaración de marcas. Es decir, si el primer o el último carácter en la declaración de una marca (markupdecl arriba) está contenido en el texto de reemplazo para una referencia a entidad parámetro, ambos deben estar contenidos en el mismo texto de reemplazo.

Restricción de Buena-Formación: PEs en el Subconjunto Interno
En el subconjunto del DTD interno, las referencias a entidades parámetro sólo 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 parámetro externas o en el subconjunto externo.)

Como en el subconjunto interno, el subconjunto externo y cualquier entidad parámetro externa referenciada en el DTD debe consistir de una serie de declaraciones completas de marcas de los tipos permitidos por el símbolo no-terminal markupdecl, intercaladas con espacios en blanco o referencias a entidades parámetro. Sin embargo, porciones de los contenidos del subconjunto externo o de las entidades parámetro externas pueden ser ignoradas condicionalmente mediante la utilización de la construcción sección condicional; esto no está permitido en el subconjunto interno.

El subconjunto externo y las entidades parámetro externas también difieren del subconjunto interno en que en ellos, las referencias a entidades parámetro son permitidas dentro de las declaraciones de marcas, no sólo entre de ellas.

Un ejemplo de un documento XML con una declaración de tipo de documento:

El identificador de sistema "hola.dtd" proporciona el URI de una DTD para el documento.

Las declaraciones pueden también darse localmente, como es este ejemplo:

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 Declaración de Documento Standalone

Las declaraciones de marcas pueden afectar al contenido de un documento, como cuando se pasan de un procesador XML a una aplicación; un ejemplo de esto son los valores por defecto de los atributos y las declaraciones de entidades. La declaración de documento standalone, que puede aparecer como componente de la declaración XML, señala si existen o no dichas declaraciones que aparecen externamente a la entidad documento.

En la declaración 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 parámetro externa referenciada desde el subconjunto interno) que afecte a la información pasada desde el procesador XML a la aplicación. El valor "no" indica que existe o que pueden haber dichas declaraciones externas de marcas. La declaración de documento standalone sólo 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 declaración de documento standalone no tiene sentido. Si, por el contrario, existiesen, pero no hay ninguna declaración de documento standalone, se asume el valor "no".

Cualquier documento XML para el cual standalone="no" puede convertirse algorítmicamente en un documento standalone, el cual puede ser necesario para algunas aplicaciones de envío en un entorno de redes.

Restricción de Validez: Declaración de Documento Standalone
La declaración de documento standalone debe tener el valor "no" si cualquier declaración 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 normalización, donde el atributo aparece en el documento con un valor que cambiará como resultado de la normalización, o
• tipos de elementos con contenido de elemento, si aparecen espacios en blanco directamente dentro de cualquier instancia de esos tipos.

Un ejemplo de declaración XML con una declaración de documento standalone:

2.10 Manejo de "Espacios en Blanco"

En la edición de documentos XML, suele ser conveniente utilizar "espacios en blanco" (espacios, tabuladores y líneas en blanco, denotadas por el no terminal S en esta especificación) para mantener la legibilidad de las marcas. Generalmente estos caracteres no deben incluirse en una posible versión distribuible del documento a través de una red. Por otro lado, existen ocasiones en las que es deseable la existencia de esos "espacios", por ejemplo en poesía y en la representación de código fuente.

Un procesador XML debe pasar siempre todos los caracteres de un documento, que no sean marcas, a la aplicación. Un procesador XML validador debe informar también a la aplicación acerca de los caracteres que constituyen los "espacios en blanco" contenidos en el contenido del elemento.

Un atributo especial denominado xml:space puede ser adjuntado a un elemento para señalar la necesidad de mantener los caracteres "espacio" en dicho elemento. Los "espacios" deben ser preservados por las aplicaciones. En los documentos válidos, 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:

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 declaración 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 raíz de los documento, por defecto, no requiere el manejo especial de "espacios" de la aplicación, si no tiene declarado este atributo.

2.11 Manejo "Fines de Línea"

Las entidades analizadas XML son frecuentemente almacenadas en archivos de ordenador, y por conveniencia de edición, están organizados en líneas. Estas líneas están típicamente separadas por una combinaciones de caracteres formada por "retorno de carro" (#xD) y "fin de línea" (#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 aplicación el carácter #xA. (Este comportamiento puede ser producido mediante la normalización de todos los "fines de línea" a caracteres #xA antes de ser analizados).

2.12 Identificación del Lenguaje

En el procesado de documentos, suele ser útil la identificación 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 válidos, 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 Identificación de Lenguajes":

La producción Langcode puede ser cualquiera de las siguientes:

• un código de dos letras como se define en la norma [ISO 639], "Códigos para la representación 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 número de segmentos Subcode. Si el primer segmento de subcódigo existe y ese subcódigo consiste en dos letras, éste debe pertenecer al código de un país de la norma [ISO 3166], "Códigos para la representación de nombres de países". Si el primer subcódigo contiene más de dos letras, éste debe ser un subcódigo para el lenguaje en cuestión, registrado por la IANA, a no ser que Langcode comience por el prefijo "x-" o "X-".

Se suele acordar dar el código del lenguaje en minúsculas, y el código del país (si tuviese) en mayúsculas. Hay que resaltar que estos valores, a diferencia del resto de nombres en XML, son representables indistintamente en minúsculas o en mayúsculas.

Por ejemplo:

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 declaración para xml:lang puede tomar la forma:

pero también pueden darse los valores por defecto específicos. En una colección de poemas franceses para estudiantes ingleses, con notas en inglés, el atributo xml:lang puede ser declarado de la siguiente manera:

3. Estructuras Lógicas

Cada documento XML contiene uno o más elementos, cuyos límites están delimitados por etiquetas de comienzo y etiquetas de fin, o en los elementos vacíos, por una etiqueta de elemento vacío. Cada elemento tiene un tipo, identificado por un nombre, a veces denominado "identificador genérico" (GI: Generic Identifier), y puede tener un conjunto de especificaciones de atributos. Cada una de éstas tiene un nombre y un valor.

Esta especificación no restringe la semántica, la utilización, o (más 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 están reservados para estandarización en esta o en futuras versiones de esta especificación.

Restricción de Buena-Formación: Igual de Tipo de Elemento
El Nombre en la etiqueta de fin de un elemento debe ser igual al de la etiqueta de comienzo.

Restricción de Validez: Elemento Válido
Un elemento es válido si existe una declaración 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 declaración cumple la regla EMPTY y el elemento no tiene contenido.
2. La declaración cumple la regla 'children' y la secuencia 'elementos child' pertenece al lenguaje generado por la expresión 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 declaración cumple la regla 'Mixed' y el contenido de la misma consiste en datos carácter y 'elementos child' cuyos tipos sean iguales a los nombres del modelo de contenido.
4. La declaración cumple la regla ANY, y los tipos de cualquier 'elemento child' han sido declarados.

3.1 Etiquetas de Comienzo, Etiquetas de Fin y Etiquetas de "Elementos-Vacíos"

El comienzo de todo elemento XML no vacío está marcado por una etiqueta de comienzo.

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.

Restricción de Buena-Formación: Especificación de Atributo Único
ningún nombre de atributo puede aparecer más de una vez en la misma etiqueta de comienzo o de "elemento-vacío".

Restricción 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").

Restricción de Buena-Formación: No Referencia a Entidades Externas
Los valores de los atributos no pueden contener entidades referencia directas o indirectas a entidades externas.

Restricción 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 "&lt;") no debe contener el carácter <.

Un ejemplo de etiqueta de comienzo podría ser:

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:

Un ejemplo de etiqueta de fin:

El texto entre las etiquetas de comienzo y de fin se denomina contenido:

Si un elemento está vacío, debe ser representado por una etiqueta de comienzo seguida de una etiqueta de fin, o por una etiqueta de "elemento-vacío". Una etiqueta de "elemento-vacío" tiene la siguiente forma:

Las etiquetas de "elemento-vacío" pueden ser utilizadas por cualquier elemento que no tenga contenido, sea o no declarado mediante la utilización de la palabra clave EMPTY. Por interoperatividad, la etiqueta de "elemento-vacío" debe ser utilizada, y sólo puede ser utilizada, en elementos que estén declarados como EMPTY.

Ejemplos de "elementos-vacíos":

3.2 Declaraciones de Tipo de Elemento

La estructura elemento de un documento XML puede, a efectos de validación, estar restringida mediante la utilización de declaraciones de tipos de elementos y de listas de atributos. Una declaración 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 declaración menciona un tipo de elemento para el que no se ha dado una declaración, como opción del usuario, dado que esto no supone ser un error.

Una declaración de tipo de elemento es de la forma:

donde la producción Name proporciona el tipo de elemento que se está declarando.

Restricción de Validez: Declaración Única de Tipo de Elemento
Ningún tipo de elemento debe ser declarado más de una vez.

Ejemplos de declaraciones de tipo de elemento:

3.2.1 Contenido del Elemento

Un tipo de elemento tiene contenido del elemento cuando los elementos de ese tipo deben contener sólo elementos hijos (no datos carácter), opcionalmente separados por "espacios en blanco" (caracteres que cumplan la regla S). En este caso, la restricción incluye un modelo de contenido, una gramática simple que gobierna los tipos de 'elementos hijo' permitidos y el orden en que pueden aparecer. La gramática está constituida por partículas de contenido (cps), que consisten en nombres, 'listas de selección' de partículas de contenido o 'listas secuencia' de partículas de contenido:

donde cada 'Name' es el tipo de un elemento que puede aparecer como un 'child'. Cualquier partícula de contenido en una lista de selección puede aparecer en el contenido del elemento donde la lista de selección aparece en la gramática. Las partículas 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 carácter opcional que sigue a un nombre o una lista gobierna si el elemento o las partículas de contenido en la lista pueden aparecer una o más veces (+), cero o más (*), o cero o una vez (?). La ausencia de dicho operador significa que el elemento o partícula de contenido debe aparecer exactamente una vez. Esta sintaxis y su significado son idénticos a los utilizados en las reglas de producción de esta especificación.

El contenido de una elemento es igual al modelo de contenido si y sólo si es posible trazar una ruta a través del modelo de contenido, obedeciendo la secuencia, opción y operadores de repetición 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 documento puede ser igual a más de una ocurrencia de un tipo de elemento en el modelo de contenido. Para más información, ver "E. Modelos de Contenido Deterministas".

Restricción de Validez: Grupo apropiado/Anidamiento de PEs
Las entidades parámetro texto de reemplazo deben ser anidadas apropiadamente con grupos de paréntesis. Es decir, si cualquiera de los paréntesis de apertura o de cierre de una construcción choice, seq o Mixed está contenida en el texto de reemplazo para una entidad parámetro, ambas deben estar contenidas en el mismo texto de reemplazo. Por interoperatividad, si una entidad parámetro aparece en una construcción choice, seq o Mixed, su texto de reemplazo no tendría que estar vacío, y ni el primero ni el último carácter 'no-blanco' del texto de reemplazo debe ser un 'conector'. (| o ,).

Ejemplos de modelos de contenido de elemento:

3.2.2 "Contenido Mezclado"

Un tipo de elemento tiene "contenido mezclado" cuando los elementos de ese tipo pueden contener datos carácter, opcionalmente entremezclados con elementos child. En este caso, los tipos de los elementos 'child' pueden ser restringidos, pero no su orden o su número de apariciones:

donde las construcciones Name dan los tipos de los elementos que pueden aparecer como hijos.

Restricción de Validez: No Duplicación de Tipos
El mismo nombre no debe aparecer más de una vez en una sola declaración de "contenido mezclado".

Ejemplos de declaraciones de contenido mezclado:

3.3 Declaraciones de Listas de Atributos

Los atributos se utilizan para asociar pares nombre-valor con elementos. Las especificaciones de atributos pueden aparecer sólo dentro de las etiquetas de comienzo y en las etiquetas de elemento vacío. Las reglas de producción utilizadas para reconocer su aparición en "3.1 Etiquetas de Comienzo, Etiquetas de Fin y Etiquetas de Elementos-Vacíos". 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:

La expresión Name en la regla AttlistDecl es tipo del elemento. Como opción de usuario, los procesadores XML pueden indicar si los atributos están declarados para un tipo de elemento que no está declarado, hecho que no constituye un error. La expresión Name en la regla AttDef es el nombre del atributo.

Cuando se proporciona más de una AttlistDecl para un tipo de elemento dado, los contenidos de todos esas declaraciones se entremezclan. Cuando se proporciona más de una definición para el mismo atributo de un tipo de elemento dado, se mantiene la primera declaración y se ignora el resto. Por interoperatividad, los creadores de DTDs deben proporcionar, al menos, una declaración de lista de atributos para un tipo de elemento dado, una definición de atributo para un nombre de atributo dado, y por lo menos una definición de atributo en cada declaración de lista de atributos Por interoperatividad, los procesadores XML pueden indicar una alerta cuando se proporciona más de una declaración de lista de atributos para un tipo de elemento dado, o más de una definición de atributo para una atributo dado. Esta es una opción de usuario y no supone ningún 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 léxicas y semánticas variantes, como se describe a continuación:

Restricción de Validez: ID
Los valores de tipo ID deben ser iguales a la regla de producción Name. Un nombre no puede aparecer más de una vez de un documento XML como valor de este tipo. P.e.: los valores de ID sólo deben identificar a los elementos que los producen.

Restricción de Validez: Un ID por Tipo de Elemento
Ningún tipo de elemento puede tener más de un atributo ID especificado.

Restricción de Validez: Atributo por Defecto ID
Un atributo ID debe tener declarado por defecto el valor #IMPLIED o #REQUIRED.

Restricción de Validez: IDREF
Los valores del tipo IDREF deben ser iguales a la regla de producción 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 algún atributo ID.

Restricción de Validez: Nombre de Entidad
Los valores del tipo ENTITY deben ser iguales a la regla de producción 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.

Restricción de Validez: Nombre de Token
Los valores del tipo NMTOKEN deben ser iguales a la regla de producción 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 declaración. Existen dos tipos de tipos enumerados:

Un atributo NOTATION identifica una notación, declarada en la DTD con su sistema asociado y/o identificadores públicos, para ser utilizados en la interpretación del elemento al cual está unido el atributo.

Restricción de Validez: Atributos de Notación
Los valores de este tipo deben ser iguales a los del nombre de notación incluidos en la declaración. Todos los nombres de notación de la declaración deben ser declarados.

Restricción de Validez: Enumeración
Los valores de este tipo deben ser iguales a los de los tokens Nmtoken de la declaración.

Por interoperatividad, no puede aparecer el mismo Nmtoken más de una vez en los tipos de atributos enumerados de un único tipo de elemento.

3.3.2 Atributos por Defecto

Una declaración de atributos proporciona información 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.

En una declaración de atributo, #REQUIRED significa que ese atributo debe ser dado siempre, #IMPLIED que no se da un valor por defecto. Si la declaración 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.

Restricción de Validez: Atributo Requerido
Si la declaración por defecto es la palabra clave #REQUIRED, el atributo debe ser especificado para todos los elementos del tipo de la declaración de la lista de atributos.

Restricción de Validez: Atributo por Defecto Legal
El valor por defecto declarado debe cumplir las restricciones léxicas del tipo de atributo declarado.

Restricción 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:

CURSO DE XLM PARTE 2