[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 [email protected]. Si se trata de un error en la traducci�n, por favor h�ganlo a [email protected]
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