[This local archive copy mirrored from the canonical site: http://www.promeko.com/informatica/gtsx/Rec-xml.html; alternately (later) from http://www.hispalinux.es/~olea/sgml-esp/Rec-xml.html. Local links may not have complete integrity, so use the canonical document at this URL if possible.]
El Lenguaje Extensible de Marcas (XML) es un subconjunto de SGML, que se describe completamente en este documento. Sus objetivos son habilitar el SGML genérico para que pueda ser servido, recibido y procesado en la Web de la manera que no es posible con HTML. XML ha sido diseñado para facilitar la implementación e interoperatividad con SGML y HTML.
Este documento ha sido revisado por los miembros del W3C y otras partes interesadas, y ha sido refrendada por el Director como una Recomendación 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 Recomendación es el de potenciar a la especificación 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 estándar internacional de procesamiento de texto existente, el Lenguaje Generalizado Estándar 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 técnicos en http://www.w3.org/TR.
Esta especificación utiliza el término 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 especificación está disponible en http://www.w3.org/XML/xml-19980210-errata (inglés).
Por favor informen de los errores en este documento a xml-editor@w3.org. Si se trata de un error en la traducción, por favor háganlo a xml@earthcorp.com
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.
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:
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.
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:
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".
Un objeto de texto es un documento XML bien-formado si:
document.| Documento | ||||
|
Cumplir la producción document implica que:
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.
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.
| Rango de Caracteres | ||||||
|
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".
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.
| Espacios en Blanco | ||||
|
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.
| Nombres y "Tokens" | ||||||||||||||||||||
|
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.
| Literales | ||||||||||||||||||||||||||||
|
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 "&" y "<" respectivamente. El paréntesis angular de cierre (>) puede ser representado utilizando la cadena ">", y debe, por compatibilidad, ser "escapado" utilizando ">" 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 "'", y el comilla doble (") como """.
| Datos Carácter | ||||
|
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.
| Comentarios | ||||
|
Un ejemplo de comentario:
<!-- declaraciones de <head> y <body> --> |
Las Instrucciones de Procesamiento (PIs) permiten a los documentos contener instrucciones para las aplicaciones.
| Instrucciones de Procesamiento | ||||||||
|
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.
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 "]]>":
| Secciones CDATA | ||||||||||||||||
|
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 "<" ni "&". 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:
<![CDATA[<saludo>Hola, mundo!</saludo>]]> |
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:
<?xml version="1.0"?> |
y también lo es:
<saludo>Hola, mundo!</saludo> |
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.
| Prolog | ||||||||||||||||||||||||
|
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".
| Definición de Tipo de Documento | ||||||||||||||||||
|
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.
| Subconjunto Externo | ||||||||
|
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:
<?xml version="1.0"?> |
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:
<?xml version="1.0" encoding="UTF-8" ?> |
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.
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.
| Declaración de Documento Standalone | ||||||
|
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:
amp, lt, gt, apos, quot), si las referencias a esas entidades aparecen en el documento, o Un ejemplo de declaración XML con una declaración de documento standalone:
<?xml version="1.0" standalone='yes'?> |
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:
<!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 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.
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).
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":
| Identificación de Lenguaje | ||||||||||||||||||||||||
|
La producción Langcode puede ser cualquiera de las siguientes:
i-" (o "I-")x-" o "X-", de manera que se asegure que no entran en conflicto con nombres que puedan ser estandarizados o registrados por la IANAPuede 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:
<p xml:lang="en">The quick brown fox jumps over the lazy dog.</p> |
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:
xml:lang NMTOKEN #IMPLIED |
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:
<!ATTLIST poema xml:lang NMTOKEN 'fr'> |
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.
| Elemento | ||||||||||||||||
|
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:
EMPTY y el elemento no tiene contenido.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'.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.ANY, y los tipos de cualquier 'elemento child' han sido declarados.El comienzo de todo elemento XML no vacío está marcado por una etiqueta de comienzo.
| 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 "<") no debe contener el carácter <.
Un ejemplo de etiqueta de comienzo podría 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 | ||||
|
Un ejemplo de etiqueta de fin:
</defterm> |
El texto entre las etiquetas de comienzo y de fin se denomina contenido:
| Contenido de los Elementos | ||||
|
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:
| Etiquetas para Elementos Vacíos | ||||||
|
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":
<IMG align="left" |
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:
| Declaración de Tipo de Elemento | ||||||||||
|
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:
<!ELEMENT br EMPTY> |
Un tipo de element 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:
| Modelos de Contenido de Elemento | ||||||||||||||||||||
|
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 debe 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:
<!ELEMENT especif (frente, cuerpo, epilogo?)> |
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:
| Declaración de "Contenido Mezclado" | ||||||||||||||||
|
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:
<!ELEMENT p (#PCDATA|a|ul|b|i|em)*> |
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 element 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:
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 | ||||||||
|
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.
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:
| Tipos de Atributos | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
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:
| Tipos de Atributos 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.
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.
| Atributos por Defecto | ||||||||||||||||||||||||||||
|
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:
<!ATTLIST defterm |
Antes de que el valor de un atributo se pase a la aplicación o se compruebe su validez, el procesador XML debe normalizarlo como se indica a continuación:
Si el valor declarado no es de tipo CDATA, el procesador XML debe procesar el valor de atributo normalizado, mediante el descartado de cualquier carácter espacio (#x20) por delante o por detrás, y mediante el reemplazo de secuencias de caracteres espacio (#x20) por un único carácter espacio (#x20).
Todos los atributos para los que no se ha leído la declaración debe ser tratado por un analizador no validador como se declara en CDATA.
Las secciones condicionales son porciones del subconjunto externo de la declaración de tipo de documento que están incluidas en, o excluidas de, la estructura lógica de la DTD basada en la palabra clave que las gobierna.
| Sección Condicionales | ||||||||||||||||||||
|
Como ocurre con los subconjuntos de la DTD internos y externos, una sección condicional puede contener una o más declaraciones completas, comentarios, instrucciones de procesamiento o secciones condicionales anidadas, entremezcladas con espacios en blanco.
Si la palabra clave de la sección condicional es INCLUDE, los contenidos de la sección condicional son parte de la DTD. Si la palabra clave es por el contrario IGNORE, los contenidos de la sección condicional no son parte lógica de la DTD. Hay que subrayar que para poder realizar un análisis con confianza, incluso los contenidos de la secciones condicionales ignoradas debe ser leído para poder detectar secciones condicionales anidadas y asegurar que el final de la sección ignorada más extrema se detecta de manera adecuada. Si una sección condicional con la palabra clave INCLUDE aparece dentro de una sección condicional más grande con la palabra clave IGNORE, ambas, la más exterior y la interior son ignoradas.
Si la palabra clave de la sección condicional es una referencia a entidad parámetro, la entidad parámetro debe ser reemplazada por su contenido antes de que el procesador decida si incluye o ignora la sección condicional.
Un ejemplo:
<!ENTITY % borrador 'INCLUDE' > |
Un documento XML puede consistir de una o más unidades de almacenamiento. Estas se denominan entidades, y todas ellas poseen contenidos y todas son (excepto la entidad documento, ver más abajo, y el subconjunto externo de la 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 notación asociada, identificada por su nombre. A parte de la necesidad de que los procesadores XML hagan accesibles los identificadores de la entidad y la notación a la aplicación, XML no impone ningún otro tipo de restricciones a los contenidos de las entidades no analizadas.
Las entidades analizadas son invocadas por su nombre mediante la utilización 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 especificación, las entidades generales son referenciadas, a veces, simplemente con el término entidad, siempre y cuando no se produzcan ambigüedades. Las entidades parámetro 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 más, ocupan diferentes espacios de nombres. Pueden existir una entidad parámetro y una entidad general con el mismo nombre, dado que son entidades diferentes.
Una referencia a carácter hace referencia a un carácter especifico del conjunto de caracteres de la norma ISO/IEC 10646. Un ejemplo puede ser un carácter no accesible directamente a través de los dispositivos de introducción de datos.
| Referencia a Carácter | ||||||||||
|
Restricción de Buena-Formación: Carácter Legal
Los caracteres referenciados mediante la utilización de referencias a caracteres deben cumplir los requisitos de la regla de producción Char.
&#x", los dígitos y las letras que le siguen hasta la aparición de ; proporcionan una representación hexadecimal del punto código del carácter en la norma ISO/IEC 10646. Si comienza por "&#", los dígitos que aparecen hasta la aparición de ; indican una representación decimal del punto código de carácter.
Una referencia a entidad referencia al contenido de una entidad con nombre. Las referencias a entidades generales analizadas utilizan el carácter ampersand (&) y, el punto y coma (;) como delimitadores. Las referencias a entidades parámetro utilizan el signo de porcentaje (%) y el punto y coma (;) como delimitadores.
| Referencia a Entidad | ||||||||||||||||||||||||||||||||||||||||||||||
|
Restricción de Buena-Formación: Entidad Declarada
En los documentos sin ningún DTD, un documento con sólo un subconjunto de DTD interno que no contiene referencias a entidades parámetro, o un documento con la cláusula "standalone='yes'", el símbolo Name dado en la referencia a entidad debe ser igual al dado en una declaración de entidad/A>, excepto en los documentos bien-formados que utilicen las entidades predeclaradas: amp, lt, gt, apos, quot. La declaración de las entidades parámetro deben preceder a cualquier referencia a ellas. De igual manera, las declaración de las entidades generales debe preceder a cualquier referencia a ellas que aparezca en la declaración de los valores por defecto de una lista de atributos. Si las entidades se declaran en el subconjunto externo o en las entidades parámetro externas, los procesadores no validadores no están obligados a leer y procesar sus declaraciones. Para esos documentos, la regla que dice que una entidad debe ser declarada es una restricción de buena-formación sólo si se da lo siguiente: standalone='yes'.
Restricción de Validez: Entidad Declarada
En los documentos con un subconjunto externo o entidades parámetro externas con la expresión "standalone='no'", el Name dado en la referencia a entidad debe ser igual al dado en una declaración de entidad. Por interoperatividad, los documentos válidos deberían declarar las entidades amp, lt, gt, apos, quot, de la manera especificada en la sección "4.6 Entidades Predefinidas". La declaración de una entidad parámetro debe preceder a cualquier referencia a ella. De manera similar, la declaración de una entidad general debe preceder a cualquier referencia a ella que aparezca en la declaración de los valores por defecto de una lista de atributos.
Restricción de Buena-Formación: Entidad Analizada
Una referencia a entidad no debe contener el nombre de una entidad no analizada. Las entidades no analizadas sólo pueden ser referenciadas en valores de atributos declarados para ser del tipo ENTITY o ENTITIES.
Restricción de Buena-Formación: No Recursión
Una entidad analizada no debe contener una referencia recursiva a sí misma, ni directa ni indirectamente.
Buena-Formación Restricción: En DTD
Las referencias a entidades parámetro sólo pueden aparecer en la DTD.
Ejemplos de referencias a caracteres y entidades:
Pulse <tecla>menor</tecla> (<) para guardar las opciones. |
Ejemplos de referencias a entidades parámetro:
<!-- declarar la entidad parámetro "ISOLat2"... --> |
Las entidades son declaradas de este modo:
| Declaración de Entidades | ||||||||||||||||||||
|
El símbolo 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 más de una vez, se le vincula la primera declaración encontrada. Como opción de usuario, los procesadores XML pueden indicar si las entidades pueden ser declaradas múltiples veces.
Si la definición de entidad es un EntityValue, la entidad definida se denomina entidad interna. No existe ningún objeto físico de almacenamiento separado, y el contenido de la entidad se da en la declaración. 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: véase "4.5 Construcción de Texto de Reemplazo de Entidad Interna".
Una entidad interna es una entidad analizada.
Un ejemplo de una declaración de entidad interna:
<!ENTITY Estado-Pub "Esta es una pre-edición de la |
Si la entidad no es interna, es una entidad externa, declarada como sigue:
| Declaración de Entidad Externa | ||||||||||||||
|
Si NDataDecl está presente, ésta es una entidad no analizada general, sino, es una entidad analizada.
Restricción de Validez: Notación Declarada
El Name debe ser igual al nombre declarado de una notación.
A SystemLiteral se le denomina identificador de sistema de la entidad. Es un URI que puede ser utilizado para obtener la entidad. El símbolo de 'sostenido' (#) y el identificador de fragmento frecuentemente utilizados con URIs no son, formalmente, parte del propio URI. Los procesadores XML podrían señalar un error si es dado un identificador de fragmento como parte de un identificador de sistema. Si no se proporciona otra información fuera del ámbito de esta especificación (e.g. un tipo especial de elemento XML definido por una DTD particular, o una instrucción de procesamiento definida por la especificación de una aplicación particular), los URIs relativos son relativos a la localización del recurso dentro del que ocurre la declaración de entidad. Un URI podría ser relativo a la entidad documento, a la entidad que contenga el subconjunto de DTD externa, o a alguna otra entidad parámetro externa.
Los procesadores XML deberían manejar los caracteres no ASCII en un URI mediante la representación del carácter en UTF-8 como uno o más de bytes, y después 'escapar' estos bytes con el 'mecanismo de escapado' de los URIs (e.g., convirtiendo cada byte a %HH, donde HH es la notación hexadecimal del valor del byte).
Adicionalmente al identificador de sistema, un identificador externo puede incluir un identificador público. Los procesadores XML que traten de obtener el contenido de la entidad pueden utilizar el identificador público 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 público deben ser normalizadas a caracteres espacio únicos (#x20), y deben eliminarse los espacios en blanco del comienzo y del final.
Un ejemplo de declaración de entidad externa:
<!ENTITY abrir-trampa |
Las entidades analizadas externas pueden empezar, cada una de ellas, con una declaración de texto.
| Declaración de Texto | ||||
|
La declaración de texto debe ser proporcionada literalmente, no por referencia a una entidad analizada. Ninguna declaración de texto puede aparecer en cualquier posición que no sea el comienzo de una entidad analizada externa.
La entidad documento está bien-formada si cumple la producción denominada document. Una entidad analizada general externa está bien-formada si cumple la producción denominada extParsedEnt. Una entidad parámetro externa está bien-formada si cumple la producción denominada extPE.
| Entidad Analizada Externa Bien-Formada | ||||||||
|
Una entidad analizada general interna está bien-formada si su texto de reemplazo cumple la producción denominada content. Todas las entidades parámetro internas están bien-formadas por definición.
Una consecuencia de la buena-formación en entidades es que las estructuras lógica y física en los documentos XML están anidadas apropiadamente. Ninguna etiqueta de comienzo, etiqueta de fin, etiqueta de elemento vacío, elemento, comentario, instrucción de procesamiento, referencia a carácter o referencia a entidad puede comenzar en una entidad y terminar en otra.
Cada entidad analizada externa en un documento XML puede utilizar una codificación 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 Apéndice B de Unicode (el carácter 'ZERO WIDTH NO-BREAK SPACE', #xFEFF). Esta es una señal de codificación, no parte de la marcación o de los datos carácter del documento XML. Los procesadores XML deben ser capaces de utilizar este carácter para diferenciar entre documentos codificados en UTF-8 o en UTF-16.
Aunque sólo 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 codificación que no sea UTF-8 o UTF-16 deben comenzar con una declaración de texto que contenga una declaración de codificación:
| Declaración de Codificación | ||||||||||
|
en la entidad documento, la declaración de codificación es parte de la declaración XML. La regla EncName es el nombre de la codificación utilizada.
En las declaraciones de codificación, 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 codificación de JIS X-0208-1997. Los procesadores XML deberían reconocer otras codificaciones, se recomienda que sean las codificaciones de caracteres registradas (como charsets) por la Internet Assigned Numbers Authority [IANA], otras codificaciones sólo serán referenciadas mediante la utilización de sus nombres registrados. Estos nombres registrados están definidos para no ser sensibles al tipo, por lo que los procesadores que quieran contemplarlos deberán tratarlos de ese modo.
En la ausencia de información proporcionada por un protocolo de transporte externo (e.g. HTTP o MIME), es un error que una entidad incluya una declaración de codificación para ser presentada al procesador XML en una codificación diferente a la nombrada en la declaración, que una declaración de codificación 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 declaración de codificación utilice una codificación que no sea UTF-8. Dado que ASCII es un subconjunto de UTF-8, no es estrictamente necesaria una declaración de codificación para las entidades ordinarias ASCII.
Se produce un error fatal si un procesador XML encuentra una entidad con una codificación que es incapaz de procesar.
Ejemplos de declaraciones de codificación:
<?xml encoding='UTF-8'?> |
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:
content.AttValue.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.EntityValue.EntityValue o de AttValue.| Tipo Entidad | Carácter | ||||
| Parámetro | Interna General |
Externa Analizada General |
No Analizada | ||
| 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 |
Fuera de la DTD, el carácter % no tiene un significado especial; de este modo, lo que sería una referencia a una entidad parámetro en una DTD no es reconocido como marcación 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.
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 carácter y marcaciones (excepto para entidades parámetro), que deben ser reconocidos de la forma habitual, a no ser que el texto de reemplazo de las entidades utilizado para 'escapar' delimitadores de marcación (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 carácter es incluida cuando el carácter indicado es procesado en lugar de la referencia propiamente dicha.
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 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 aplicación que reconoció, pero que no leyó, la entidad.
Esta regla se basa en el reconocimiento que la inclusión automática proporcionada por SGML y el mecanismo de entidad XML, principalmente diseñada para soportar la modularidad en la creación. No es necesariamente apropiada para otras aplicaciones, en particular para visualización de documentos. Los visualizadores, por ejemplo, cuando encuentran una referencia a entidad externa analizada, pueden elegir entre proporcionar una indicación visual de la presencia de la entidad y obtenerla para su visualización bajo demanda.
Los siguientes están prohibidos y constituyen errores fatales:
EntityValue o de un AttValue.Cuando una referencia a entidad aparece en un valor de atributo, o una referencia a entidad parámetro 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 carácter comilla simple o doble en el texto de reemplazo que siempre es tratado como un dato carácter normal y no terminará el literal. Por ejemplo, esto está bien-formado:
<!ENTITY % SN '"Sí"' > |
mientras que esto no lo está:
<!ENTITY FinAtrib "27'" > |
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 aplicación sobre los identificadores de sistema y públicos (si hubiese alguno) para ambas entidades y su notación asociada.
Cuando aparece una referencia a entidad general en EntityValue en una declaración de entidad, es obviado y dejado como está.
Tal como ocurre con las entidades externas analizadas, las entidades parámetro sólo necesitan ser incluidas si se valida. Cuando una referencia a entidad parámetro es reconocida en la DTD e incluida, su texto de reemplazo es alargado mediante la adición de carácter de comienzo y un carácter espacio (#x20). La intención es restringir el texto de reemplazo a entidades parámetro para contener un número integral de 'tokens' gramaticales en la DTD.
En la discusión 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 declaración de la entidad, correspondiente al no terminal EntityValue. El texto de reemplazo es el contenido de la entidad, después del reemplazo de las referencias a caracteres y a entidades parámetro.
El valor literal de la entidad como se da en una declaración de entidad interna (EntityValue) puede contener caracteres, entidades parámetro 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 parámetro referenciadas, y debe contener el carácter referenciado, en lugar de cualquier referencia a carácter en el valor literal de la entidad. Sin embargo, las referencias a entidades generales deben ser dejadas como están, sin expandir. Por ejemplo, dadas las siguientes declaraciones:
<!ENTITY % editorial "Éditions Gallimard" > |
luego el texto de reemplazo para la entidad "libro" es:
La Peste: Albert Camus, |
La referencia a entidad general "&derechos;" sería 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 discusión detallada de un ejemplo difícil, véase "D. Expansión de Referencias a Entidades y Caracteres".
Las referencias a entidades y a caracteres pueden ser utilizadas para 'escapar' el paréntesis angular de apertura, el ampersand y otros delimitadores. Se especifica un conjunto de entidades generales para (amp, lt, gt, apos, quot) este propósito. También se pueden utilizar referencias a caracteres numéricos, que se expanden inmediatamente cuando son reconocidas y deben ser tratadas como datos carácter, por lo que las referencias a caracteres numéricos "<" y "&" pueden ser utilizadas para 'escapar' < y & cuando aparecen en los datos carácter.
Todos los procesadores XML deben reconocer estas entidades bien si son declaradas o no. Por interoperatividad, los documentos XML válidos deberían declarar estas entidades, como cualesquiera otras, antes de utilizarlas. Si las entidades en cuestión son declaradas, deben ser declaradas como entidades internas cuyo texto de reemplazo sea únicamente el carácter 'escapado' o una referencia a carácter a dicho carácter en sí, como se muestra abajo.
<!ENTITY lt "&#60;"> |
Los caracteres < y & en las declaraciones de "lt" y "amp" son 'escapados' doblemente para satisfacer los requerimientos de la buena-formación de entidades de reemplazo.
Las notaciones identifican por su nombre el formato de las entidades no analizadas, el formato de los elementos que dependen de un atributo de notación, o la aplicación a la que instrucción de procesamiento está destinada.
Las declaraciones de notación proporcionan un nombre para la notación, 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 notación que pueda permitir que los procesadores XML o sus aplicaciones clientes localicen aplicaciones auxiliadora capaz de procesar datos en la notación dada.
| Declaraciones de Notación | ||||||||
|
los procesadores XML deben proporcionar a las aplicaciones el nombre y el/los identificador/es externos de cualquier notación 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 aplicación pedir al procesador los datos en la notación descrita. (No es un error, sin embargo, que los documentos XML declaren y referencien a notaciones para las cuales no hay disponibles aplicaciones de notación específica en sistemas donde está ejecutándose el procesador XML o la aplicación).
La entidad documento sirve como raíz del árbol de entidades y de punto de comienzo para los procesadores XML. Esta especificación no especifica cómo 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 ningún tipo de identificación.
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-formación de esta especificación, 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 especificación. 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 sólo tienen que leer la entidad documento, incluyendo el subconjunto de DTD interno completo, para determinar la buena-formación. Aunque no se requiera la comprobación 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 parámetro que lean, a partir de la primera referencia a entidades parámetro que no lean, es decir, deben utilizar la información 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 después de una referencia a una entidad parámetro que no es leída, dado que la entidad puede contener declaraciones anulantes.
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-formación 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:
Para una máxima fiabilidad en la interoperatividad entre los diferentes procesadores, las aplicaciones que utilicen procesadores no validadores deberían 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 deberían utilizar procesadores XML validadores.
La gramática formal de XML se da en esta especificación utilizando una notación 'Backus-Naur Extendida' (EBNF) muy simple. cada regla de la gramática define un símbolo, de la forma
símbolo ::= expresión |
Los símbolos se escriben con una letra mayúscula inicial si son definidos por una expresión regular o sino, con una letra minúscula inicial. Las cadenas literales se entrecomillan.
En la expresión de la parte derecha de una regla, las siguientes expresiones se utilizan para contener a cadenas de uno a más caracteres:
#xNN es un entero hexadecimal. Esta expresión se refiere a un carácter de la norma ISO/IEC 10646 cuyo valor canónico (UCS-4), se interpreta como un número binario sin signo, con el valor indicado. El número de ceros por la izquierda en la expresión #xN es insignificante. Éstos son gobernados por el correspondiente valor de la codificación utilizada y no son significativos para XML.[a-zA-Z], [#xN-#xN][^a-z], [^#xN-#xN][^abc], [^#xN#xN#xN]"cadena"'cadena'A y B representan expresiones simples:expresión)expresión es tratada como una unidad y puede ser combinada como se describe en esta lista.A?A o nada; A opcional.A BA seguida de una B.A | BA o B pero no ambas.A - BA pero que no contenga B.A+A.A*A./* ... */[ rbf: ... ][ rv: ... ]Siguiendo con las características definidas en el estándar Unicode, los caracteres se clasifican en caracteres base (estos contienen los caracteres alfabéticos de alfabeto latino, sin símbolos diacríticos), caracteres ideográficos y caracteres combinatorios (que contienen a la mayoría de caracteres diacríticos). Estas clases se combinan para formar la clase de las letras (letters). Los dígitos y los 'extensores' también se distinguen.
| Caracteres | ||||||||||||||||||||||||
|
Las clases de caracteres definidas aquí pueden ser derivadas de la base de datos Unicode, de la siguiente manera:
XML está diseñado para ser un subconjunto de SGML, por lo tanto todo documento XML válido también debe ser un documento SGML "conformado". Para una comparación detallada de las restricciones adicionales que XML impone a los documentos SGML, ver [Clark].
Este apéndice contiene algunos ejemplos que ilustran la secuencia de reconocimiento de referencias a entidades y caracteres y su expansión, como se especifica en la sección "4.4 Tratamiento de Entidades y Referencias por el Procesador XML".
Si la DTD contiene la declaración
<!ENTITY ejemplo "<p>Un ampersand (&#38;) puede ser "escapado" |
entonces el procesador XML reconocerá las referencias a caracteres cuando analice la declaración de entidad, y las resolverá antes de almacenar la siguiente cadena como el valor de la entidad "ejemplo":
<p>Un ampersand (&) puede ser "escapado" |
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" serán reconocidas y las tres referencias serán 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 más complejo puede ilustrar las reglas y sus todos sus efectos. En el siguiente ejemplo, los números de línea sólo son una referencia.
1 <?xml version='1.0'?> |
Esto produce lo siguiente:
xx" se almacena en el tabla de símbolos con el valor "%zz;". Dado que el texto de reemplazo no es releído, la referencia a la entidad parámetro "zz" no es reconocida. (y se producirá un error si "zz" no estuviese declarado todavía.)<" se expande inmediatamente y la entidad parámetro "zz" se almacena con el texto de reemplazo "<!ENTITY falso "error" >", que es una declaración de entidad bien-formada.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".falso" es reconocida, y se expande, por lo que el contenido completo del elemento "prueba" es la cadena autodescrita Este ejemplo muestra un método error.Por compatibilidad, se requiere que los modelos de contenido en las declaraciones de tipo de elemento sean determinísticas.
SGML requiere modelos de contenido determinísticos (se denominan "no ambiguos"). Los procesadores XML construidos utilizando sistemas SGML pueden indicar modelos de contenido no determinísticos como errores.
Por ejemplo, el modelo de contenido ((b, c) | (b, d)) no es determinístico 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, sólo 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 aceptarán.
Más formalmente: se puede construir un autómata de estados finitos partiendo del modelo de contenido, mediante la utilización de algoritmos estándares (p.e. el algoritmo 3.5 de la sección 3.9 de Aho, Sethi y Ullman [Aho/Ullman]). En muchos otros algoritmos, se construye un conjunto para cada posición de una expresión regular (p.e. cada nodo hoja en el árbol sintáctico de una expresión regular). Si cualquier posición tiene un conjunto en el cual más de una posición está etiquetada con el mismo nombre de tipo de elemento, el modelo de contenido es erróneo y hay que informar de su existencia.
Existen algoritmos que permiten reducir automáticamente muchos, pero no todos los modelos de contenido no determinísticos a determinísticos. Ver Brüggemann-Klein 1991 [Brüggemann-Klein].
La declaración de codificación XML funciona como una etiqueta interna en cada entidad, indicando que codificación de caracteres se está utilizando. Antes de que un procesador XML pueda leer la etiqueta interna, sin embargo, éste debe aparentemente, conocer que codificación 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 implementación debe soportar sólo un conjunto finito de codificaciones de caracteres, y la declaración de codificación de XML está restringida en posición y contenido, para hacerla más sencilla para la autodetección de la codificación que se está utilizando en cada entidad. Además, en muchos casos, también están disponibles adicionalmente otras fuentes de información, 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 información externa. Siempre consideramos la primera opción primero.
Dado que cada entidad XML que no pertenezca a los formatos UTF-8 o UTF-16 debe comenzar con una declaración de codificación XML, donde los primeros caracteres deben ser '<?xml', cualquier 'procesador conformador' puede detectar, después 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)00 3C 00 00: UCS-4, unusual octet order (3412)FE FF: UTF-16, big-endianFF FE: UTF-16, little-endian00 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 codificación en 7-bit, 8-bit ó híbrida, que asegure que los caracteres ASCII tienen su posición, anchura y valores normales. La declaración de codificación actual debe ser leída para detectar cual de estas aplicar, pero dado que todas estas codificaciones utilizan los mismos patrones de bits para los caracteres ASCII, la declaración de codificación debe ser leída de manera exacta4C 6F A7 94: EBCDIC (toda la declaración de codificación debe ser leída para indicar que página de código se está utilizando)Este nivel de autodetección es suficiente para leer la declaración de codificación XML y para analizar el identificador de codificación 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 página del código EBCDIC especifica en uso, etc).
Dado que los contenidos de la declaración de codificación están restringidos a caracteres ASCII, los procesadores pueden leer con exactitud toda la declaración de codificación tan pronto como hayan detectado que familia de codificaciones está en uso. En la práctica, todas las codificaciones ampliamente utilizadas entran en alguna de las categorías descritas arriba. La declaración de codificación XML permite un razonable aseguramiento del etiquetado de codificación de caracteres, incluso cuando fuentes externas de información en el sistema operativo o el nivel de protocolo de transporte no lo aseguren.
Una vez que el procesador ha detectado la codificación en uso, puede actuar apropiadamente, bien invocando a una rutina de entrada externa para cada caso, o bien llamando a la función de conversión apropiada para cada carácter de entrada.
Como cualquier sistema de 'auto-etiquetado', la declaración de codificación de XML no funcionará si cualquier software cambia el conjunto de caracteres o la codificación de la entidad sin actualizar dicha declaración. Los implementadores de rutinas de codificación de caracteres deberían ser cuidadosos para asegurar exactitud de la información interna y externa utilizada para etiquetar la entidad.
El segundo caso posible ocurre cuando la entidad XML está acompañada de información de codificación, como en algunos sistemas de archivos y algunos protocolos de red. Cuando múltiples fuentes de información están disponibles, su prioridad relativa y el método 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, deberían ser parte del documento RFC que definiría los tipos MIME "text/xml" y "application/xml". Por razones de interoperatividad, sin embargo, se recomiendan las siguientes reglas.
conjunto de caracteres (charset)' del tipo MIME determina el método de codificación de caracteres. El resto de heurísticas y fuentes de información sólo se utilizan para recuperación de errores. Esta especificación ha sido preparada y aprobada para su publicación por el Grupo de Trabajo (GT) XML del W3C. La aprobación de esta especificación por parte del GT no implica necesariamente que todos los miembros del GT hayan votado su aprobación. Los miembros actuales del GT XML son:
Jon Bosak, Sun (Presidente); James Clark (Dirección Técnica); 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