Este documento puede contener errores de traducción, los cuales deben ser reportados a Fabio Arciniegas A. La siguiente es la traducción del estado del documento original:
Este documento [el original] ha sido revisado por los miembros de la W3C y otras partes interesadas y ha sido declarada por el Director como una recomendación de la W3C. Es un documento estable y puede ser usado como material de referencia o citado como una referencia normativa desde otro documento. El rol de la W3C al hacer la recomendación es llamar la atención hacia la misma y promover su amplio despliegue. Esto amplía la funcionalidad e interoperabilidad de la Web.
El lenguaje extensible de marcas (XML) es un subconjunto de SGML, el cual
está completamente definido en este documento. Su objetivo es permitir que
SGML genérico pueda ser servido, recibido y procesado en la web en la misma
manera que hoy es posible con HTML. XML ha sido diseñado de tal manera que sea
fácil de implementar y buscando interoperabilidad tanto con SGML como con
HTML.
Este documento [el original] ha sido revisado por los miembros de la W3C y
otras partes interesadas y ha sido declarada por el Director como una
recomendación de la W3C. Es un documento estable y puede ser usado como
material de referencia o citado como una referencia normativa desde otro
documento. El rol de la W3C al hacer la recomendación es llamar la atención
hacia la misma y promover su amplio despliegue. Esto amplía la funcionalidad e
interoperabilidad de la Web.
Este documento especifica la sintaxis de un subconjunto de un estándar
existente y ampliamente usado de procesamiento de texto(Standard Generalized
Markup Language), ISO 8879: 19886(E)). Dicho subconjunto permite su uso en la
WWW. Es un producto de la W3C XML Activity, cuyos detalles pueden ser
encontrados en: http://www.w3.org/XML. Una
lista de las actuales recomendaciones y otros documentos técnicos de la W3C
pueden ser encontrados en http://www.w3.org/TR.
El lenguaje extensible de marcas, abreviado XML, describe una clase de
objetos de datos llamados documentos
XML y parcialmente describe el comportamiento de programas de computador
que pueden procesarlos. XML es un perfil de aplicación o forma restringida de
SGML (Standard Generalized Markup Language) [ISO
8879]. Por construcción, todo documento conforme con XML es conforme con
SGML.
XML fue desarrollado por un Grupo de Trabajo de XML (originalmente conocido
como el comité de revisión editorial de SGML) formado bajo el auspicio del
World Wide Web Consortium (W3C) en 1996. Estaba presidido por Jon Bosak de Sun
Microsystems con la participación activa de un Grupo Especial de Interés en
XML (previamente conocido como el grupo de trabajo de SGML) también organizado
por el W3C. Los miembros del grupo de trabajo de XML están dados en un
apéndice. Dan Connolly sirvió como el contacto del grupo con la W3C.
- XML debe ser utilizable directamente sobre internet.
- XML debe soportar una amplia variedad de aplicaciones.
- XML debe ser compatible con SGML.
- Debe ser fácil escribir programas que procesen documentos XML.
- El número de características opcionales en XML debe ser mantenido en un mínimo, idealmente cero.
- Los documentos XML deben ser legibles por un humano y razonablemente claros.
- El diseño de XML debe ser preparado rápidamente
- El diseño de XML debe ser formal y conciso.
- Los documentos XML deben ser fáciles de crear.
- La brevedad en la marcación es de mínima importancia
- Esta especificación, junto con los estándares asociados (Unicode and
ISO/IEC 10646 para caracteres, Internet RFC 1766 para las marcas de
identificación de lenguaje, ISO 639 para los códigos de nombre de lenguaje,
ISO 3166 para los códigos de nombre de país), provee toda la información
necesaria para entender XML Version 1.0 y construir programas de computador
que lo procesen.
Esta versión de la especificación de XML puede ser distribuida
libremente, mientras todo el texto y las anotaciones legales permanezcan
intactas.
La terminología utilizada para describir documentos XML está definida en
el cuerpo de está especificación. Los términos definidos en la siguiente
lista son usados por estas definiciones y en la descripción de acciones de
un procesador de XML:
- puede
- [Definición:] Los documentos conformes y
procesadores de XML tienen permitido, mas no es obligatorio, comportarse
como es descrito.
- debe/tiene que
- Documentos conformes y procesadores de XML tienen como requisito
comportarse como se describe; de lo contrario, son erróneos.
- error
- [Definición:] Una violación de las reglas de esta
especificación; los resultados no estan definidos. Software conforme puede
detectar y reportar un error y puede recuperarse de él.
- error fatal
- [Definición:] Un error tal que un Procesador
de XML conforme, debe detectar y reportar a la aplicación. Después de
encontrar un error fatal, el procesador puede continuar procesando los
datos con el fin de buscar más errores, los cuales puede reportar a su vez
a la aplicación. Para dar soporte a la corrección de errores, el
procesador puede hacer del documento datos sin procesar (es decir, una
mezcla de datos y marcas) disponibles para la aplicación. Una vez un error
fatal es detectado, el procesador no puede continuar procesando
normalmente. (i.e., No debe continuar pasando datos de caracter e
información acerca de la estructura lógica del documentos a la aplicación
de una forma normal.
- a elección/opción del usuario
- Software conforme puede o debe comportarse como es descrito; Si lo
hace, debe proveer al usuario con los medios para activar o desactivar el
comportamiento descrito.
- restricciones de validez
- Una regla que aplica a todo documento válido
de XML. Las violaciones de restricciones de validez son errores; Estas
deben, a opción del usuario, ser reportadas por un procesador
de XML validador.
- restricciones de buena formación(well
formedness)
- Una regla que aplica a todos los documentos XML bien-formados
Violaciones de las restricciones de buena formación son
href="#dt-fatal">errores fatales.
- emparejamiento (match)
- [Definición:] (De cadenas o nombres:) Dos cadenas o nombres comparados
deben ser idénticos. Los caracteres con múltiples posibles en ISO/IEC
10646 (e.g. caracteres con formas a la vez precompuestas y
base+diacrítico) se emparejan sólo si tienen la misma representación en
ambas cadenas. A opción del usuario, un procesador puede normalizar tales
caracteres a alguna forma canónica.. Ningún cambio de mayúsculas es
ejecutado. (De cadenas y reglas en la gramática:) Una cadena se empareja
con una producción gramatical si pertenece al lenguaje generado por dicha
producción. . (De contenido y modelos de contenido:) Un elemento se
empareja con su declaración cuando es conforme en la forma descrita en la
restricción "Elemento
Válido".
- para compatibilidad/con fines de compatibilidad
- [Definición:] Una
característica de XML incluida solamente para asegurar que XML se mantenga
compatible con SGML.
- para interoperabilidad/con fines de interoperabilidad
- [Definición:] Una
recomendación incluida para incrementar las posibilidades de que
documentos XML puedan ser procesados por los existentes procesadores de
SGML que son anteriores al anexo de adaptaciones de WebSGML al ISO
8879.
[Definición:] Un objeto de
datos es un Documento XML si es bien
formado, tal y como es definido en esta especificación. Un documento XML
bien formado puede ser adicionalmente válido
si cumple con algunas restricciones adicionales.
Cada documento XML tiene una estructura tanto lógica como física.
Físicamente, el documento está compuesto de unidades llamadas entidades.
Una entidad puede referirse
a otras entidades con el fin de causar su inclusión en el documento. Un
documento comienza en una "raíz" o entidad
documento. Lógicamente, el documento está compuesto de declaraciones,
elementos, comentarios, referencias de caracter e instrucciones de proceso.
Todo lo anterior está indicado en el documento mediante marcas explícitas.
Las estructuras lógicas y físicas deben anidarse apropiadamente, tal y como
es descrito en "4.3.2 Entidades
procesadas bien formadas".
[Definición:] Un objeto de
texto es un documento XML bien formado si:
- Tomado como un todo, se empareja con la producción marcada como
documento.
- Cumple con todas las restricciones acerca de buena-formación dadas en
esta especificación
- Cada una de las entidades
procesadas referenciadas directa o indirectamente en el documento es
bien
formada.
Note que por razones de brevedad y claridad, en las producciones de ebnf
-como está- se ha mantenido el original en inglés
Emparejar con la producción documento
implica que:
- Contiene uno o más elementos.
- [Definición:] Existe
exactamente un elemento llamado la
raíz, o elemento documento; ninguna parte de dicho elemento
aparece en el contenido
de ningún otro elemento. Para todos los demás elementos, si la
marca de comienzo está en el contenido de otro elemento, la marca de fin
está en el contenido del mismo elemento. Dicho de otra manera más simple,
los elementos, delimitados por marcas de comienzo y fin se anidan
apropiadamente.
[Definición:] Una
consecuencia de esto es que, por cada elemento no
raíz H en
el documento, existe otro elemento F en el documento tal que
H está en el contenido de F, pero no en el
contenido de ningún otro elemento que esté en el contenido de
F. A F se le refiere como el padre de
H, y a H como el hijo de
F.
[Definición:] Una entidad
procesada contiene texto, una secuencia de caracteres,
los cuales pueden representar marcas o datos de caracter. [Definición:] Un caracter es
una unidad atómica de texto tal y como está especificada por ISO/IEC 10646
[ISO/IEC
10646]. Los caracteres legales son tab, retorno de carro (carriage
return), avance de línea(linefeed) y los caracteres gráficos legales de
Unicode e ISO/IEC 10646. El uso de "caracteres de compatibilidad", tal y
como están definidos en la sección 6.8 de [Unicode],
no es aquí promovido.
| Rango de caracteres |
| [2] |
Char |
::=
|
#x9 | #xA | #xD
| [#x20-#xD7FF] | [#xE000-#xFFFD]
| [#x10000-#x10FFFF] |
/*
|
cualquier caracter Unicode,
excluyendo los bloques surrogados, FFFE, y FFFF.
*/ | |
El mecanismo para codificar puntos de código de caracter en patrones de
bits puede variar de entidad a entidad. Todos los procesadores de XML deben
aceptar las codificaciones UTF-8 y UTF-16 del 10646; los mecanismos para
señalar cual de los dos está en uso, o para traer otra codificación a juego,
son discutidos luego en "4.3.3 Codificación
de caracteres en entidades".
Esta sección define algunos símbolos ampliamente usados en la
gramática.
S
(espacio en blanco) consiste de uno o más caracteres de espacio (#x20),
retornos de carro, avances de línea o tabuladores.
| Espacio en blanco |
| [3] |
S |
::=
|
(#x20 | #x9 | #xD
| #xA)+ | |
Los caracteres son clasificados por conveniencia como letras, dígitos u
otros caracteres. Las letras consisten de un caracter alfabético o silábico
de base posiblemente seguido por uno o más caracteres de combinación, o por
un caracter ideográfico. La completa definición de los caracteres en cada
clase está dada en "B. Clases
de caracter".
[Definición:] Un Nombre es
un token que comienza con una letra o un caracter que pertenece a cierto
grupo de caracteres de puntuación, y continúa con letras, dígitos, guiones,
subrayados(underscores), comas o puntos, los cuales, juntos, son conocidos
como caracteres de nombre. Los nombres que comienzan con la cadena
"xml", o cualquier cadena que empareje con (('X'|'x')
('M'|'m') ('L'|'l')), está reservada para estandarización en ésta o
futuras versiones de la especificación.
Nota: El caracter de dos puntos en nombres está reservado para la
experimentación con espacios de nombres. Su significado se espera sea
estandarizado en algún punto futuro, en el cual los documentos que utilicen
el punto para fines experimentales deberán ser actualizados. (No hay
garantía de que algún mecanismo de espacios de nombre adoptado para XML vaya
en efecto a usar los dos puntos como su delimitador de espacios de nombre.)
En la práctica, esto significa que los autores no deben utilizar dos puntos
en nombres de XML excepto como parte de experimentos de espacios de nombre,
pero que los procesadores de XML deben aceptar el punto como un caracter de
nombre.
Un Nmtoken
(Token de nombre -name token-) Es cualquier mezcla de caracteres de nombre.
Los datos literales son cualquier cadena entre comillas(citada) que no
contenga la marca de cita usada como delimitadora para tal cadena. Los
literales son usados para especificar el contenido de entidades internas (EntityValue),
valores de atributos (AttValue),
e identificadores externos (SystemLiteral).
Note que un SystemLiteral
puede ser procesado sin tener que ser auscultado buscando marcas.
| Literales |
| [9] |
EntityValue |
::=
|
'"' ([^%&"]
| PEReference
| Reference)*
'"' |
| |
|
|
| "'" ([^%&']
| PEReference
| Reference)*
"'" |
| [10] |
AttValue |
::=
|
'"' ([^<&"]
| Reference)*
'"' |
| |
|
|
| "'" ([^<&']
| Reference)*
"'" |
| [11] |
SystemLiteral |
::=
|
('"' [^"]* '"') | ("'"
[^']* "'") |
| [12] |
PubidLiteral |
::=
|
'"' PubidChar* '"'
| "'" (PubidChar -
"'")* "'" |
| [13] |
PubidChar |
::=
|
#x20 | #xD | #xA
| [a-zA-Z0-9]
| [-'()+,./:=?;!*#@$_%] | |
El
texto consiste de datos
de caracter y de marcación. [Definición:] La marcación toma la forma de marcas o
tags de comienzo, tags de
finalización, tags de
elementos vacíos, referencias
de entidad, referencias
de caracter, comentarios,
delimitadores de secciones
CDATA, declaraciones
de tipo de documento, e instrucciones
de procesamiento.
[Definición:] Todo texto que
no sea marcación constituye los datos de caracter del
documento.
El caracter de ampersand (&) y el caracter de "menor que" (<)
pueden aparecer en su forma literal sólo cuando son usados como
delimitadores de marcación, o dentro de comentarios,
una instrucción
de procesamiento, o una sección
de CDATA. Son también legales dentro del valor
literal de entidad de una declaración de entidad interna; ver "4.3.2 Entidades
procesadas bien-formadas". Si son necesitadas en otro lugar, deben ser
"escapadas"
usando, bien sea referencias
numéricas a caracteres o las cadenas "&" y
"<" respectivamente. El símbolo de "mayor que" (>)
puede ser representado usando la cadena ">", y debe, por
compatibilidad, ser escapado usando ">" o una
referencia de caracter cuando aparezca en la cadena "]]>" en
contenido, cuando dicha cadena no es la marca de finalización de una CDATA
sección.
En el contenido de elementos, los datos de caracter son cualquier cadena
de caracteres que no contenga el delimitador de comienzo de ninguna
marcación. En una sección CDATA, los datos de caracter son cualquier cadena
de caracteres que no incluya el delimitador de cierre de sección de CDATA,
"]]>".
Para permitir que los valores de atributos contengan tanto comillas
simples como dobles, el apóstrofe o caracter de comilla sencilla (') puede
ser representada como "'", y el caracter de comilla
doble (") como """.
| Datos de caracter |
| [14] |
CharData |
::=
|
[^<&]* - ([^<&]*
']]>'
[^<&]*) | |
[Definición:] Los
comentarios pueden aparecer en cualquier lugar de un documento fuera de
otras marcas;
Adicionalmente pueden aparecer en lugares permitidos por la gramática. No
son parte de los datos
de caracter de un documento; un procesador de XML puede, pero no tiene
que, hacer posible que la aplicación recupere el texto de comentarios. Por
compatibilidad, la cadena "--" (doble guión) no debe
ocurrir dentro de comentarios.
| Comentarios |
| [15] |
Comment |
::=
|
'<!--' ((Char - '-')
| ('-' (Char - '-')))*
'-->' | |
Un ejemplo de comentario:
<!-- declarations for <head> & <body> --> |
[Definición:] Las instrucciones
de procesamiento (IPs) permiten a los documentos incluir instrucciones
para las aplicaciones.
| Instrucciones de procesamiento |
| [16] |
IP |
::=
|
'<?' PITarget
(S
(Char* -
(Char* '?>'
Char*)))?
'?>' |
| [17] |
PITarget |
::=
|
Name - (('X'
| 'x') ('M' | 'm') ('L'
| 'l')) | |
Las IPs no son parte de los datos
de caracter del documento, pero deben ser pasados a la aplicación. Las
IP comienzan con un objetivo (PITarget)
usado para identificar la aplicación para la cual la instrucción está
dirigida. Los nombres de objetivo como "XML" y
"xml", están reservadas para estandarización en ésta o futuras
versiones de esta especificación. El mecanismo de Notación
de XML puede ser usado para la declaración formal de objetivos de IP.
[Definición:] Las
secciones CDATA pueden ocurrir en cualquier lugar en que pueda ocurrir
un datos de caracter; son usadas para escapar bloques de texto que contengan
caracteres que de otro modo serían reconocidos como marcas. Las secciones
CDATA comienzan con la cadena "<![CDATA[" y terminan con la
cadena "]]>":
Dentro de una sección CDATA, sólo la cadena de CDEnd
es reconocida como marcación, asi que los caracteres de "menor que" y
ampersand pueden ocurrir en su forma literal; no necesitan (ni pueden) ser
escapados usando "<" y "&". Las
secciones CDATA no pueden ser anidadas.
Un ejemplo de una sección CDATA, en la cual
"<greeting>" and "</greeting>" son
reconocidos como datos
de caracter, no como marcas:
<![CDATA[<greeting>Hello, world!</greeting>]]> |
[Definición:] Los documentos
XML pueden, y deben, empezar con una declaración de XML la cual
específica la versión de XML usada. Por ejemplo, el siguiente es un
documento completo de XML, bien-formado
pero no válido:
<?xml version="1.0"?>
<greeting>Hello, world!</greeting>
|
también lo es esto:
<greeting>Hello, world!</greeting>
|
El número de versión "1.0" debe ser usado para indicar
conformidad con esta versión de la especificación; es un error usar el valor
"1.0" si no es conforme con esta versión de la especificación.
Es la intención del grupo de trabajo de XML dar nuevas versiones de esta
especificación diferentes a "1.0", no obstante, esta intención
no indica un compromiso de producir versiones futuras de XML, ni tampoco, en
caso de ser producidas, de usar ningún esquema de numeración en particular.
Ya que las versiones futuras no están reglamentadas, esta construcción se
provee como un medio para permitir el chequeo automático de versiones, si
éste se vuelve necesario. Un procesador puede señalar un error si recibe
documentos marcados con versiones que no soporta.
La función de la marcación en un documento de XML es describir su
almacenamiento y estructura lógica y asociar pares de atributos-valores con
sus correspondientes estructuras lógicas. XML provee un mecanismo, la declaración
de tipo de documento (document type declaration), con el fin de
describir restricciones en la estructura lógica y soportar el uso de
unidades de almacenamiento predefinidas. [Definición:] Un documento de XML es válido si tiene
un asociada una declaración de tipo de documento y es conforme con las
restricciones que en ella se expresan.
La declaración de tipo de documento debe aparecer antes del primer elemento
en el documento.
[Definición:] La declaración
de tipo de documento de XML contiene o apunta a declaraciones
de marcación que proveen una gramática para una clase de documentos.
Esta gramática es conocida como una Definición de Tipo de Documento
(Document type Definition), o DTD. La declaración de tipo de
documento puede apuntar a un subconjunto externo (un tipo especial de entidad
externa)que contenga declaraciones de marcación, o puede contener las
declaraciones de marcación directamente en un subconjunto interno, o puede
hacer ambas cosas. El DTD de un documento consiste de ambos subconjuntos
unidos.
[Definición:] 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 dadas total o
parcialmente dentro de entidades de
parámetro, como es descrito en las restricciones de buena-formación y
validez mostradas más adelante. Para ver la información completa, ver "4. Estructuras
Físicas".
| Definición de Tipo de Documento |
|
|
Las declaraciones de marcación pueden estar hechas total o parcialmente
por el texto
de reemplazo de entidades
parámetro. Las producciones dadas luego en esta especificación para
no-terminales individuales (elementdecl,
AttlistDecl,
etcétera) describen las declaraciones después de que todas las
entidades parámetro han sido incluidas.
Restricción de validez: Tipo del elemento
raíz
El Nombre
en la declaración de tipo de documento, debe emparejar con el tipo de
elemento del elemento
raíz.
Restricción de validez: Declaración apropiada/Anidamiento de
PE
El texto
de reemplazo de entidades parámetro(PE) debe estar apropiadamente
anidado con las declaraciones de marcación. Es decir, si el primer o último
de los caracteres de una declaración de marcación (markupdecl
arriba) está contenido en el texto de reemplazo de una referencia
a entidad parámetro, ambos deben estar contenidos en el texto de
remplazo.
Restricción de buena-formación: PEs en subconjuntos internos
En
el subconjunto interno del DTD, las
referencias a entidades parámetro pueden ocurrir sólo en aquellos
lugares donde las declaraciones de marcas puedan ocurrir, no dentro de
declaraciones de marca. (Esto no aplica a referencias que ocurran en
entidades de parámetro externas o al subconjunto externo.)
Al igual que el subconjunto interno, el subconjunto externo y cualquier
entidad parámetro externa a la cual se haga referencia en el DTD debe
consistir de una serie de declaraciones de marcas completas de los tipos
admitidos por el símbolo no-terminal markupdecl,
con la participación de espacios en blanco y
referencias a entidades parámetro. De cualquier manera, porciones del
contenido del subconjunto externo o de entidades de parámetro externas
pueden ser condicionalmente ignoradas usando la construcción sección
condicional; esto no está permitido en el subconjunto interno.
El subconjunto externo y las entidades de parámetro externas también
difieren del subconjunto interno en cuanto las
referencias a entidades parámetro son permitidas al interior de
declaraciones de demarcación, no sólo dentro de declaraciones de
demarcación.
Un ejemplo de un documento XML con una declaración de tipo de documento:
<?xml version="1.0"?>
<!DOCTYPE greeting SYSTEM "hello.dtd">
<greeting>Hello, world!</greeting>
|
El identificador
de sistema "hello.dtd" proporciona el URI de un DTD para el
documento.
Las declaraciones también pueden ser dadas localmente, tal y como se ve
en este ejemplo:
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE greeting [
<!ELEMENT greeting (#PCDATA)>
]>
<greeting>Hello, world!</greeting>
|
Si tanto el subconjunto externo como el interno son usados, el interno se
considera que ocurre antes que el externo. Esto tiene el efecto de que las
declaraciones de entidades y lista de atributos en el subconjunto interno
tienen precedencia sobre aquellas en el externo.
Las declaraciones de demarcación pueden afectar el contenido del
documento, al ser pasadas del procesador
de XML a una aplicación; ejemplos de esto son los atributos por defecto
y las declaraciones de entidades. La declaración aislada de documento, la
cual puede aparecer como un componente de la declaración de XML, señala si
existen tales declaraciones que aparezcan externas a la entidad
documento.
| Declaración de documento aislado |
|
|
En una declaración de documento aislado, el valor "yes"
indica que no existen declaraciones de marcas externas a la entidad
documento (ni en el subconjunto externo del DTD, ni el subconjunto
interno del DTD, ni en una entidad parámetro externa referenciada dentro del
subconjunto interno) que afecten la información pasada del procesador XML a
la aplicación. El valor "no" indica que hay o puede haber tales
declaraciónes de demarcación externas. Note que la declaración de documento
aislado sólo denota la presencia de declaraciones; la presencia, en
un documento, de referencias a entidades externas, cuando dichas
entidades están internamente declaradas, no cambia el estado de aislado del
documento.
Si no existen declaraciones externas de demarcación, la declaración de
documento aislado no tiene significado. Si existen declaraciones de
demarcación externas pero no existe una declaración de de documento aislado,
el valor "no" es supuesto.
Cualquier documento XML para el cual se mantiene que
standalone="no" puede ser convertido algorítmicamente a un
documento aislado, lo cual puede ser deseable para algunas aplicaciones de
envío por red.
Restricción de validez: declaración de documento aislado
la
declaración de documento aislado debe tener el valor "no" si
cualquier declaración externa de demarcación contiene declaraciones de:
- atributos con valores por defecto,
si los elementos a los cuales aplican estos atributos aparecen en el
documento sin especificar valores para dichos atributos, o
- entidades (diferentes a
amp, lt,
gt, apos, quot), si aparecen referencias
a dichas entidades en el documento, o
- atributos con valores sujetos a normalización,
donde el atributo aparezca en el documento con un valor que cambiará como
resultado de la normalización o,
- tipos de elementos con contenido
de elemento , si ocurren espacios en blanco directamente sobre
cualquier instancia de estos tipos.
Un ejemplo de una declaración de XML con una especificación de documento
aislado:
<?xml version="1.0" standalone='yes'?> |
Al editar documentos XML, es frecuentemente necesario usar "espacios en
blanco" (espacios, tabuladores y líneas en blanco, denotadas por el no
terminal S
en esta especificación) como parte de la demarcación para mejorar la
legibilidad. Dichos espacios en blanco no están típicamente puestos para ser
incluidos en la versión entregada del documento. Por otra parte, existen
espacios en blanco "significativos" que deben ser preservados en la versión
entregada, por ejemplo en poesía y código fuente.
Un procesador
de XML debe siempre pasar todos los caracteres en un documento que no
son demarcación a la aplicación. Un procesador
de XML debe además informar a la aplicación cuales de estos caracteres
constituyen espacios en blanco apareciendo en contenido
de elemento.
Un atributo
especial llamado xml:space puede ser atado a un elemento para
señalar una intención de que en ese elemento, los espacios en blanco deben
ser preservados por las aplicaciones. En documentos válidos, este atributo,
como cualquier otro, debe ser declarado
si es usado. Cuando es declarado, debe estar dado como un tipo
enumerado, cuyos únicos posibles valores son "default" y
"preserve". Por ejemplo:
<!ATTLIST poem xml:space (default|preserve) 'preserve'> |
El valor "default" señala que los modos de proceso de
espacios en blanco de las aplicaciones son aceptables para este elemento; el
valor "preserve" indica la intención de que las aplicaciones
preserven todos los espacios en blanco. Esta intención declarada se
considera que se debe aplicar a todos los elementos dentro del contenido del
elemento donde está especificado, a menos de que sea sobre-escrito en otro
atributo xml:space
El elemento
raíz de cualquier documento se considera como marcada sin
intenciones con respecto al manejo de espacios en blanco, a menos que se
provea un valor para este atributo o el atributo sea declarado con un valor
por defecto.
Las entidades
procesadas son frecuentemente almacenadas en archivos de computadores,
los cuales, por facilidad de edición, son organizados en líneas. Estas
líneas están típicamente separadas por alguna combinación de los caracteres
carriage-return (#xD) and line-feed (#xA).
Para simplificar las tareas de las aplicaciones,
en cada lugar en que una entidad externa procesada o el valor literal de una
entidad interna procesada contenga la secuencia literal de caracteres
"#xD#xA" o un literal #xD independiente, el procesador
de XML debe pasar a la aplicación el caracter sencillo #xA. (Este
comportamientos se puede reproducir convenientemente mediante la
normalización de todos los fines de línea a #xA en la entrada, antes de
procesar.)
En el procesamiento de documentos es frecuentemente útil identificar el
lenguaje natural en el cual el contenido está escrito Un atributo
especial llamado xml:lang puede ser insertado en los documentos
para especificar el lenguaje usado en el contenido y valores de atributo de
cualquier elemento en un documento XML.En documentos válidos, este atributo,
como cualquier otro, debe ser declarado
si va a ser usado. Los valores del atributo son los identificadores de
lenguaje tal y como están definidos por [IETF RFC
1766], "Tags para la identificación de lenguajes":
| Identificación de Lenguaje |
| [33] |
LanguageID |
::=
|
Langcode ('-'
Subcode)* |
| [34] |
Langcode |
::=
|
ISO639Code
| IanaCode
| UserCode |
| [35] |
ISO639Code |
::=
|
([a-z] | [A-Z]) ([a-z]
| [A-Z]) |
| [36] |
IanaCode |
::=
|
('i' | 'I') '-' ([a-z]
| [A-Z])+ |
| [37] |
UserCode |
::=
|
('x' | 'X') '-' ([a-z]
| [A-Z])+ |
| [38] |
Subcode |
::=
|
([a-z]
| [A-Z])+ | |
El código
de lenguaje puede ser uno de los siguientes:
- Un código de lenguaje de dos letras tal y como está definido por [ISO
639], "Códigos para la representación de nombres de lenguajes"
- Un identificador de lenguaje registrado ante el Internet Assigned
Numbers Authority [IANA];
Estos comienzan con el prefijo "
i-" (o "I-")
- Un identificador de lenguaje asignado por el usuario, o acordado entre
partes para uso privado; estos deben comenzar con el prefijo
"
x-" o "X-" de tal manera que se garantice que
no se tendrán conflictos con nombres luego estandarizados o registrados
ante la IANA
Puede haber cualquier número de segmentos de Subcódigo
; Si el primer segmento de subcódigo existe y el subcódigo consiste de dos
letras, entonces debe ser un código de país del [ISO
3166], "Códigos para la representación de nombres de lenguajes." Si el
primer subcódigo consiste de más de tres letras, debe ser un subcódigo para
el lenguaje en cuestión registrado con IANA, a menos de que el
código de lenguje comience con el prefijo "x-" or
"X-".
Es acostumbrado usar el código de lenguaje en minúsculas, y el código del
país (si lo hay) en mayúsculas. Note que estos valores, a diferencia de
otros nombres en los documentos XML, no son sensibles a mayúsculas (case
insensitive).
Por ejemplo:
<p xml:lang="en">The quick brown fox jumps over the lazy dog.</p>
<p xml:lang="en-GB">What colour is it?</p>
<p xml:lang="en-US">What color is it?</p>
<sp who="Faust" desc='leise' xml:lang="de">
<l>Habe nun, ach! Philosophie,</l>
<l>Juristerei, und Medizin</l>
<l>und leider auch Theologie</l>
<l>durchaus studiert mit heißem Bemüh'n.</l>
</sp> |
La intención declarada con xml:lang se considera que aplica
a todos los atributos y contenido de elementos donde fue especificada, a
menos de que sea sobreescrita por una instancia de xml:lang en
otro elemento dentro del contenido.
] | | | | | [ | VC: Element Valid
] |
Esta especificación no impone ninguna restricción sobre la semántica uso,
o (más allá de la sintaxis) nombres de los tipos de elementos y atributos,
Excepto que los nombres que comienzan con algo que se empareje con
(('X'|'x')('M'|'m')('L'|'l')) están reservados para
estandarización en ésta o futuras versiones de la especificación.
Restricción de buena-formación: Emparejamiento de tipo de elemento
El Nombre
en el tag de fin de un elemento debe emparejarse con el tipo de elemento en
el tag de comienzo.
Restricción de Validez: Elemento Válido
Un elemento es válido
si existe una declaración que empareje con elementdecl
donde el Nombre
(name en la producción) empareje con el tipo del elemento, y una
de las siguientes se cumpla:
- La declaración empareja con
EMPTY y el elemento no tiene
contenido.
- La declaración empareja con
hijo
(children) y la secuencia de elementos
hijos pertenece al lenguaje generado por la expresión regular en el
modelo de contenido, con espacios en blanco opcionales (caracteres que
emparejen con el no terminal S)
dentro de cada par de elementos hijos.
- La declaración empareja con
Mixed
y su contenido consiste de datos
caracter y elementos
hijos cuyos elementos emparejan con nombres en el modelo de contenido.
- La declaración empareja con
ANY, los tipos de cualquier
elemento
hijo han sido declarados.
[Definición:] El comienzo de todo
elemento no vacío de XML está marcado por un tag de comienzo.
El Nombre
en el tag de inicio y de fin define el tipo de elemento.. [Definición:] Las parejas Nombre
(name)-Atributo
(AttValue) son conocidas como especificaciones de atributo
del elemento , [Definición:] en donde el Nombre(name)
en cada par es conocido como el nombre de atributo y [Definición:] el contenido del Valor
(AttValue) (el texto entre delimitadores ' o
") como el valor de atributo.
Restricción de buena-formación: Especificación de atributo
única
Ningún nombre de atributo puede aparecer más de una vez en el
mismo tag de comienzo o tag de elemento vacío.
Restricción de Validez: Tipo del valor de atributo
El atributo
debe haber sido declarado; el valor puede ser del tipo declarado para él.
(Para tipos de atributos, ver "3.3 Declaraciones
de listas de atributos".)
Restricción de buena-formación: Ninguna referencia a entidad
externa
Los valores de Atributo no pueden contener referencias
directas ni indirectas a entidades externas.
Restricción de buena-formación: Ningún <
en el valor de atributo
El texto
de reemplazo de cualquier entidad a la cual se haga referencia directa o
indirectamente en un valor de atributo (diferente a "<")
no debe contener <.
Un ejemplo de un tag de comienzo:
<termdef id="dt-dog" term="dog"> |
[Definición:] El final de todo
elemento que comienza con un tag de comienzo debe estar marcado por un
tag de fin el cual contiene el nombre que hace eco al tipo del
elemento tal y como fue dado en el tag de comienzo:
Un ejemplo de un tag de fin:
[Definición:] El texto
entre el tag de comienzo y el tag de fin es llamado el contenido del
elemento:
[Definición:] Si un elemento es
vacío, debe estar representado o bien por un tag de comienzo
inmediatamente seguido de un tag de fin o por un tag de elemento vacío. [Definición:] Un tag de elemento vacío
toma una forma especial: tag de elemento vacío
| Tags para elementos vacios |
|
|
Los tags de elemento vacío pueden ser usados para cualquier elemento sin
contenido, bien sea que haya sido declarado con la palabra clave
EMPTY o no. Por
interoperabilidad, El tag de elemento vacío debe ser usado sólo para
elementos que han sido declarados
EMPTY.
Ejemplos de elementos vacíos:
<IMG align="left"
src="http://www.w3.org/Icons/WWW/w3c_home" />
<br></br>
<br/> |
La estructura de elementos
de un documento
XML puede, por propósitos de validación,
ser restringida usando declaraciones de tipo de elemento y declaraciones de
lista de atributos. Un tipo de elemento restringe el contenido
del elemento.
Las declaraciones de tipo de elemento frecuentemente restringen cuales de
los tipos de elemento pueden aparecer como hijos
del elemento. A opción del usuario, un procesador de XML puede levantar una
advertencia cuando la declaración menciona un tipo de elemento para el cual
no se ha provisto una declaración, pero esto no es un error.
[Definición:] Una declaración
de tipo de elemento declaration toma la forma:
| Declaración de tipo de elemento |
|
|
donde el Nombre
define el tipo de elemento que está siendo declarado.
Restricción de Validez: Declaración única de tipo de elemento
Ningún tipo de elemento puede ser declarado más de una vez.
Ejemplos de declaraciones de tipo de elementos:
<!ELEMENT br EMPTY>
<!ELEMENT p (#PCDATA|emph)* >
<!ELEMENT %nombre.para; %content.para; >
<!ELEMENT container ANY> |
[Definición:] Un tipo de
elemento tiene contenido de elemento cuando los elementos de ese tipo
pueden contener sólo elementos hijos
(no datos de caracter), opcionalmente separados por espacio en blanco
(caracteres que emparejen con el no-terminal S).
En este caso la restricción incluye un modelo de contenido, una
simple gramática que gobierna los tipos permitidos para los elementos hijos
y el orden en el cual pueden aparecer. La gramática está construida sobre
partículas de contenido (cps),
las cuales consisten de nombres, listas de opción de partículas de
contenido, o secuencia de listas de partículas de contenido.
| Modelos de contenido de elemento |
|
|
donde cada Nombre
es el tipo de elemento que puede aparecer como hijo.
Cualquier partícula en una lista de selección puede aparecer en el contenido
de elemento en el lugar donde la lista aparece en la gramática;
partículas de contenido que ocurren en una lista de secuencia deben aparecer
en el contenido
de elemento en el orden dado en la lista. El caracter de opcionalidad
siguiendo un nombre o una lista gobierna si el elemento o las partículas de
contenido en la lista pueden ocurrir una o más veces, (+), cero
o más (*), o cero o una vez (?). La ausencia de
tal operador significa que el elemento debe aparecer exactamente una vez.
Esta sintaxis y su significado son idénticas a las usadas en las
producciones de esta especificación.
El contenido de un elemento empareja con un modelo de contenido, si y
solo si, es posible seguir un camino a través del modelo de contenido,
obedeciendo los operadores de secuencia, elección y repetición y emparejando
cada elemento en el contenido contra un tipo de elemento en el modelo de
contenido. Por
compatibilidad, es un error si un elemento en el documento puede
emparejarse con 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 determinísticos".
Restricción de Validez: Agrupación apropiada de grupos/PE (Entidades
parámetro)
El texto
de reemplazo de entidades parámetro deben estar apropiadamente anidadas
con grupos entre paréntesis. Eso es decir, que si alguno de los paréntesis
en una construcción choice,
seq,
o Mixed
es contenida en el texto de reemplazo de una entidad de
parámetro, ambos deben estar contenidos en el mismos texto de reemplazo.
Por
interoperabilidad, si una referencia a entidad parámetro aparece en una
construcción choice,
seq,
or Mixed
, su texto de reemplazo no debe ser vacío y ni el primer ni el último
caracter del texto de reemplazo debe ser un conector (| o
,).
Ejemplos de modelos de contenido de elementos:
<!ELEMENT spec (front, body, back?)>
<!ELEMENT div1 (head, (p | list | note)*, div2*)>
<!ELEMENT dictionary-body (%div.mix; | %dict.mix;)*> |
[Definición:] Un tipo de
elemento tiene contenido mixto cuando elementos de ese tipo pueden
contener datos de caracter, opcionalmente mezclados con elementos hijos
En este caso, los tipos de los hijos pueden ser restringidos, pero no
su orden o su numero de ocurrencias:
| Declaración de contenido mixto |
|
|
donde los Nombres
dan los tipos de elementos que pueden aparecer como hijos.
Restricción de Validez: Tipos No Duplicados
El mismo nombre no
debe aparecer más de una vez en una sola declaración de contenido mixto.
Ejemplos de declaraciones de contenido mixto:
<!ELEMENT p (#PCDATA|a|ul|b|i|em)*>
<!ELEMENT p (#PCDATA | %font; | %phrase; | %special; | %form;)* >
<!ELEMENT b (#PCDATA)> |
Los Atributos
son usados para asociar pares valor-nombre con elementos.
Las especificaciones de Atributo pueden aparecer sólo dentro de tags de
comienzo y tags de
elementos vacíos; por esto, las producciones usadas para reconocerlas
aparecen en "3.1 Tags
de Comienzo, Tags de Fin y Tags de Elementos Vacios". Las declaraciones
de lista de atributos pueden ser usadas para:
- Definir un conjunto de atributos pertenecientes a un tipo de elemento
dado
- Establecer restricciones de tipo a estos atributos
- Proveer valores
por defecto para los atributos.
[Definición:] La declaración
de lista de atributos especifica el nombre, tipo de datos, y valor por
defecto (si existe) de un atributo asociado con un tipo de elemento dado:
| Declaración de lista de Atributos |
|
|
El Nombre
en la regla AttlistDecl
es el tipo de un elemento. A opción del usuario, un procesador de XML puede
levantar una advertencia si han sido declarados atributos para un elemento
que no ha sido declarado, pero esto no es un error. El Nombre
en la regla AttDef
es el nombre del atributo.
Cuando más de una AttlistDecl
es provista para algún tipo dado de elemento, el contenido de todo lo
provisto es unido. Cuando más de una definición es provista para el mismo
atributo de un tipo de elemento, la primera declaración es tomada y
declaraciones posteriores son ignoradas. Por
interoperabilidad, desarrolladores de DTDs pueden escoger proveer máximo
una declaración de lista de atributos por cada tipo de elemento, máximo una
definición por atributo y al menos una definición de atributo en cada lista
de atributos. Por interoperabilidad, un procesador de XML, puede, a opción
del usuario, levantar una advertencia cuando más de una declaración de lista
de atributos es dada para algún atributo, pero esto no es un error.
Los tipos de atributo en XML son de tres tipos: un tipo cadena, un
conjunto de tipos "tokenizados", y tipos enumerados. El tipo cadena puede
albergar cualquier cadena literal como valor; los tipos "tokenizados" tienen
restricciones léxicas y semánticas, como es anotado a continuación:
Restricción de Validez: ID
Valores del tipo ID
deben emparejarse con la producción Name.
Un nombre no debe aparecer más de una vez en un documento XML como un valor
de este tipo; i.e., Los valores ID deben identificar únicamente a los
elementos que los contienen.
Restricción de Validez: Un ID por tipo de elemento
Un tipo de
elemento no puede tener más de un atributo de ID especificado.
Restricción de Validez: Valor por defecto del atributo ID
Un
atributo ID debe tener por defecto uno declarado #IMPLIED o
#REQUIRED.
Restricción de Validez: IDREF
Valores del tipo
IDREF deben emparejarse con la construcción Name
, y los valores del tipo IDREFS con la producción Names;
cada Name
debe emparejar con el valor de un atributo ID en algún elemento en el
documento XML; i.e. los valores IDREF deben emparejar el valor
de algunos de estos atributos ID.
Restricción de Validez: Nombre de Entidad
Los valores del tipo
ENTITY deben emparejarse con la producción Name
, los valores del tipo ENTITIES deben emparejarse con la
producción Names;
cada Nombre
debe emparejar con el nombre de una entidad
no procesada declarada en el DTD.
Restricción de Validez: Token de nombre
Valores del tipo
NMTOKEN deben emparejarse con la producción Nmtoken;
Valores del tipo NMTOKENS deben emparejarse con Nmtokens.
[Definición:] Los Tipos
enumerados de datos pueden tomar un valor de la lista provista en la
declaración. Existen dos tipos de datos enumerados:
| Tipos enumerados de atributo |
|
|
Un atributo NOTATION identifica una notación,
declarada en el DTD con identificadores de sistema y/o públicos asociados,
para ser usada en la interpretación del atributo asociado.
Restricción de Validez: Atributos de Notación
Los valores de
este tipo deben emparejarse con uno de los nombres de notación
incluidos en la declaración; todos los nombres de notación en la declaración
deben ser declarados.
Restricción de Validez: Enumeración
Los valores de este tipo
deben emparejar uno de los tokens Nmtoken
en la declaración.
Por
interoperabilidad, el mismo Nmtoken
no debe ocurrir más de una vez en los tipos enumerados de atributos de un
solo tipo de elemento 3.3.2 Valores por defecto de
Atributo
Una declaración
de atributo provee información acerca de si la presencia del atributo es
requerida y si no lo es, como un procesador de XML debe reaccionar si un
atributo declarado no está presente en el documento.
| Valores por defecto de Atributo |
|
|
En una declaración de atributo, #REQUIRED significa que el
atributo debe ser provisto siempre, #IMPLIED que no se provee
de ningún valor por defecto. [Definición:] Si la declaración bi es ni
#REQUIRED ni #IMPLIED, entonces el valor de AttValue
contiene el valor por defecto declarado; La palabra clave
#FIXED indica que el atributo siempre debe tener el valor por
defecto. Si es declarado un valor por defecto, cuando un procesador XML
encuentra que se ha omitido un atributo, se comportará como si el atributo
estuviera presente con el valor por defecto declarado.
Restricción de Validez: Atributo Requerido
Si la declaración
por defecto es la palabra reservada #REQUIRED, entonces el
atributo debe ser especificado para todos los elementos del tipo en la
declaración de la lista de atributos.
Restricción de Validez: Valor por Defecto Legal
El valor por
defecto declarado debe cumplir las restricciones léxicas del tipo de
atributo declarado.
Restricción de Validez: Valor por Defecto Fijo
Si un atributo
tiene un valor por defecto declarado con la palabra reservada
#FIXED , las instancias de dicho atributo deben emparejarse con
el valor por defecto.
Ejemplos de declaraciones de lista de atributo:
<!ATTLIST termdef
id ID #REQUIRED
nombre CDATA #IMPLIED>
<!ATTLIST list
type (bullets|ordered|glossary) "ordered">
<!ATTLIST form
method CDATA #FIXED "POST"> |
Antes de que el valor de un atributo sea pasado a la aplicación o
chequeado para ver su validez, el procesador de XML debe normalizarlo como
se describe a continuación:
- Una referencia caracter es procesada mediante la adición del caracter
referenciado al valor del atributo
- Una referencia entidad es procesada mediante el proceso recurrente de
reemplazo del texto de la entidad
- Un caracter de espacio en blanco (#x20, #xD, #xA, #x9) es procesado
mediante la adición de #x20 al valor normalizado, excepto por la adición
de un solo #x20 por la aparición de la secuencia "#xD#xA" que es parte de
una entidad externa procesada o el valor literal de entidad de una entidad
interna procesada
- otros caracteres son procesados mediante la adición de si mismos al
valor normalizado
Si el valor declarado no es CDATA, entonces el procesador debe continuar
el proceso de normalización mediante el descarte de cualquier secuencia de
espacios en blanco al comienzo o final (#x20) y mediante el reemplazo de
cualquier secuencia de espacios (#x20) por un solo caracter de espacio
(#x20).
Todos los atributos para los cuales no se hayan leído una declaración
deben ser tratados por un procesador no validador como si fuesen declarados
CDATA.
[Definición:] Las
Secciones Condicionales son porciones del subconjunto externo de la
declaración
de tipo de documento los cuales son incluidos o excluidos en la
estructura lógica del documento con base en la palabra clave que las
gobierna.
Al igual que los subconjuntos externo e interno del DTD. una sección
condicional puede contener una o más declaraciones completas, comentarios,
instrucciones de proceso o secciones condicionales anidadas, mezcladas con
espacios en blanco.
Si la palabra clave de la sección condicional es INCLUDE,
entonces los contenidos de la sección condicional son parte del DTD. Si la
palabra clave de la sección condicional es IGNORE, entonces los
contenidos de la sección condicional no hacen lógicamente parte del DTD.
Note que para un procesamiento confiable los contenidos de secciones
condicionales, aún las ignoradas, deben ser leídos con el fin de detectar
secciones anidadas y la correcta finalización de la sección condicional. Si
una sección condicional con la palabra clave INCLUDE ocurre
dentro de una sección condicional con la palabra clave IGNORE,
ambas secciones, tanto la externa como la interna, son ignoradas.
Si la palabra clave de la sección condicional es una referencia a una
entidad parámetro, la entidad debe ser primero reemplazada antes de que se
decida incluir o no la sección condicional.
Un ejemplo:
<!ENTITY % draft 'INCLUDE' >
<!ENTITY % final 'IGNORE' >
<![%draft;[
<!ELEMENT book (comments*, title, body, supplements?)>
]]>
<![%final;[
<!ELEMENT book (title, body, supplements?)>
]]>
|
[Definición:] Un documento XML
puede consistir de una o más unidades de almacenamiento. estas unidades son
llamadas entidades; todas tienen contenido y están (excepto
por la entidad documento y el subconjunto
externo del DTD) identificados por nombre. Cada documento
XML tiene una entidad llamada la entidad
documento, la cual sirve como punto de partida para el
href="#dt-xml-proc">procesador de XML, la cual puede contener todo el
documento.
Las entidades pueden ser procesadas o sin procesar (parsed or unparsed).
[Definición:] El contenido de
una entidad procesada se les refiere como el texto
de remplazo ; Este texto
es considerado una parte integral del documento.
[Definición:] Una entidad
sin procesar es un recurso cuyos contenidos pueden o no ser text, y
si lo son, tal vez no sean XML. Cada entidad sin procesar tiene una notación,
identificada por nombre. más allá del requerimiento de que un procesador de
XML debe hacer disponibles los identificadores de la entidad y la notación a
la aplicación, XML, no impone ninguna restricción en cuanto al contenido de
entidades sin procesar.
Las entidades procesadas son invocadas por nombre utilizando referencias
a entidades; las entidades no procesadas lo son por nombre, dado en el valor
de los atributos ENTITY o ENTITIES.
[Definición:] Las Entidades
Generales son entidades para ser usadas dentro del contenido del
documento. En esta especificación, las entidades generales son a veces
referidas con el término entity cuando esto no lleva a
ambiguedades. [Definición:] Las
entidades parámetro son entidades procesadas para ser usadas dentro del
DTD. Estos dos tipos de entidades usan diferentes formas de
referencia y son reconocidas en diferentes contextos. mas aún, ocupan
diferentes espacios de nombre; una entidad parámetro y una entidad general
con el mismo nombre son entidades diferentes.
[Definición:] Una referencia
caracter se refiere a un caracter específico en el conjunto de
caracteres en el ISO/IEC 10646, por ejemplo uno no directamente accesible
desde un dispositivo de entrada.
| Referencia a Caracter |
| [66] |
CharRef |
::=
|
'&#' [0-9]+ ';'
|
| |
|
|
| '&#x' [0-9a-fA-F]+
';' |
[
|
WFC: Legal Caracter
] | |
Restricción de buena-formación: Caracter Legal
Los caracteres a
los cuales se haga referencia usando referencias caracter deben emparejarse
con la producción Char.
Si la referencia caracter comienza con "&#x", los
dígitos y letras hasta el punto y coma ; de terminación proveen
una representación hexadecimal del punto de código del caracter en ISO/IEC
10646. Si comienza sólo con "&#", los dígitos hasta el
; de terminación proveen una representación decimal del punto
de código caracter.
[Definición:] Una referencia
entidad se refiere al contenido de la unidad nombrada. [Definición:] Las referencias a
entidades generales procesadas usan ampersand (&) y punto y
coma como delimitadores (;). [Definición:] Las referencias parámetro entidad usan
el símbolo de porcentaje (%) y punto y coma (;)
como delimitadores.
Restricción de buena-formación: Entidad declarada
En un
documento sin un DTD, un documento con sólo un subconjunto interno el cual
no contiene referencias a entidades parámetro, o un documento con
"standalone='yes'", el Nombre
dado en la referencia entidad debe emparejar
con aquel en la declaración
de entidad , excepto por las siguientes entidades que no es necesario
declarar en un documento bien-formado: amp, lt,
gt, apos, quot. La declaración de una
entidad parámetro debe preceder cualquier referencia a ella. Igualmente, la
declaración de una entidad general debe preceder cualquier referencia a ella
en un valor por defecto en una declaración de lista de atributos. Note que
si hay entidades declaradas en el subconjunto externo o en entidades
parámetro externas, un procesador no validador no
está obligado a leer y procesar sus declaraciones; para tales
documentos, la regla que enuncia que una entidad debe ser declarada es sólo
una Restricción de buena-formación si standalone='yes'.
Restricción de Validez: Entidad declarada
En un documento con
un subconjunto externo o entidades parámetro externas y
"standalone='no'", el Nombre
dado en la referencia entidad debe emparejar
con aquel en la declaración
de entidad. Por interoperabilidad, los documentos válidos deben declarar
las entidades, amp, lt, gt,
apos, quot, En la forma especificada en "4.6 Entidades
predefinidas ". La declaración de una entidad parámetro debe preceder
cualquier referencia a él. Similarmente, la declaración de una entidad
general debe preceder cualquier referencia a ella la cual aparezca en un
valor por defecto en una lista de declaración de atributos.
Restricción de buena-formación: Entidad procesada
Una
referencia entidad no puede contener el nombre de una
href="#dt-unparsed">entidad no procesada. Las entidades sin procesar
pueden ser referenciadas solamente en un valor de
atributo declarado de tipo ENTITY o ENTITIES.
Restricción de buena-formación: No Recursión
Una entidad
procesada no puede contener una referencia recursiva a sí misma, ni directa
ni indirectamente.
Restricción de buena-formación: En DTD
Las referencias
parámetro-entidad pueden aparecer solo en el DTD.
Ejemplos de referencias de caracter y entidad:
Type <key>less-than</key> (<) to save options.
This document was prepared on &docdate; and
is classified &security-level;. |
Ejemplo de una referencia parámetro-entidad:
<!-- declare the parameter entity "ISOLat2"... -->
<!ENTITY % ISOLat2
SYSTEM "http://www.xml.com/iso/isolat2-xml.entidades" >
<!-- ... now referencia it. -->
%ISOLat2; |
[Definición:] Las entidades son
declaradas asi:
El Nombre
identifica la entidad en una referencia
o, en el caso de una entidad no procesada, en el valor de un atributo
ENTITY o ENTIDADES. Si la misma entidad es
declarada más de una vez, la primera declaración encontrada es tomada. A
opción del usuario, un procesador XML puede levantar una advertencia si
existen entidades declaradas múltiples veces.
[Definición:] Si la
definición de entidad es una EntityValue,
la entidad definida es llamada una entidad interna. No existe una
objeto de almacenamiento separado, y el contenido de la entidad está dado en
la declaración. Note que algunos procesamientos de referencias de
caracter y entidad en el valor
literal de entidad pueden ser requeridos para producir el texto
de remplazo correcto: ver "4.5 Construcción
de texto de remplazo de entidades internas".
Una entidad interna es una entidad
procesada.
Ejemplo de una declaración de entidad interna:
<!ENTITY Pub-Status "This is a pre-release of the
specification."> |
[Definición:] Si la entidad no
es interna, es entonces una entidad externa, declarada como:
| Declaración de entidad externa |
|
|
Si el NDataDecl
está presente, ésta es una entidad
no procesada general; de otro modo, es una entidad procesada.
Restricción de Validez: Notación declarada
Nombre
debe emparejarse con el nombre declarado de una notación.
[Definición:] El SystemLiteral
es llamado la entidad identificadora de sistema. Es un URI, el cual
puede ser usado para traer la entidad. Note que la marca de número
(#) y el identificador de fragmento frecuentemente usados en
URIs no son, formalmente, parte del URI mismo; un procesador XML puede
señalar un error si un identificador de fragmento es dado como parte de un
identificador de sistema. A menos de que sea dicho de otra forma por
información fuera del alcance de este documento (e.g. un elemento especial
definido en un DTD particular, o una instrucción de procesamiento definida
para una aplicación en particular), los URIs son relativos a la ubicación
del recurso dentro del cual dicha declaración ocurre. Un URI puede entonces
ser relativo a la entidad
documento, a la entidad que contiene el subconjunto
externo, o a alguna otra entidad
de parámetro externa.
Un procesador debe manejar todos los caracteres no ASCII en un URI
representando el caracter en UTF-8 como uno o más caracteres, y escapando
éstos bytes con el mecanismo de escape de las URI (i.e. convirtiendo cada
bite a %HH, donde HH es la notación hexadecimal del valor del byte).
[Definición:] En adición al
identificador del sistema, un identificador externo puede incluir un
identificador público. Un procesador XML que esté intentando
traer el contenido de la entidad puede usar el identificador público para
intentrar generar un URI alternativo. Si el procesador no puede hacerlo,
debe utilizar el URI especificado en el literal de sistema. Antes de
intentar un emparejamiento, todas las cadenas de espacios en blanco en el
identificador público deben ser normalizadas a un espacio sencillo (#x20)
todo espacio en blanco al comienzo o final debe ser removido.
Ejemplos de declaraciones de entidades externas:
<!ENTITY open-hatch
SYSTEM "http://www.textuality.com/boilerplate/OpenHatch.xml">
<!ENTITY open-hatch
PUBLIC "-//Textuality//TEXT Standard open-hatch boilerplate//EN"
"http://www.textuality.com/boilerplate/OpenHatch.xml">
<!ENTITY hatch-pic
SYSTEM "../grafix/OpenHatch.gif"
NDATA gif > |
Las entidades procesadas externas pueden comenzar cada una con una
declaración de texto.
La declaración de texto debe ser provista literalmente, no por referencia
a una entidad procesada. Ninguna declaración de texto debe aparecer en
ninguna otra posición diferente al comienzo de una entidad externa
procesada.
La entidad documento está bien formada si se empareja con la producción
marcada documento.
Una entidad externa procesada es bien formada si se empareja con la
producción marcada como extPE.
| Entidades procesadas bien formadas |
|
|
Una entidad interna procesada es bien formada si su texto de remplazo se
empareja con la producción marcada como content.
Todas las entidades de parámetro internas están bien formadas por
definición.
Una consecuencia de la buena formación es que las entidades están
apropiadamente anidadas ;ningún tag de
comienzo, tag de
fin, tag de
elemento vacío, elemento,
comentario,
instrucción
de procesamiento, referencia
a caracter, o referencia
a entidad puede comenzar en una entidad y terminar en otra.
Cada entidad externa procesada en un documento XML puede usar una
codificación diferente para sus caracteres. Todos los procesadores de XML
deben estar en capacidad de leer entidades tanto en UTF-16 y UTF8.
Las entidades codificadas en UTF-16 deben comenzar con la marca de orden
de byte descrita en el Anexo E de ISO/IEC 10646 y Unicode apendice B (el
caracter ZERO WIDTH NO-BREAK , #xFEFF -ancho cero no fin-). Esta es una
firma de codificación, no parte de las marcas ni de los datos de caracter
del documento. Los procesadores de XML deben estar en capacidad de usar este
caracter para diferenciar entre documentos codificados en UTF-8 y aquellos
codificados en UTF-16.
Aunque solamente es requerido que los procesadores lean entidades en
codificaciones UTF-8 y UTF-16, es reconocido que existen otras
codificaciones usadas en el mundo y puede ser deseable que procesadores de
XML lean entidades que las usan. Entidades procesadas que se encuentran
almacenadas en codificaciones diferentes a UTF-8 or UTF-16 deben comenzar
con una declaración
de texto que contenga una declaración de codificación:
| Declaración de codificación |
| [80] |
EncodingDecl |
::=
|
S 'encoding'
Eq ('"'
EncNombre '"'
| "'" EncNombre "'"
) |
| [81] |
EncNombre |
::=
|
[A-Za-z] ([A-Za-z0-9._]
| '-')* |
/*
|
Encoding nombre contains only
Latin caracteres
*/ | |
En la entidad
documento, la declaración de codificación es parte de la declaración
XML. El EncNombre
es el nombre de la codificación usada.
En una declaración de codificación, los valores "UTF-8",
"UTF-16", "ISO-10646-UCS-2", y
"ISO-10646-UCS-4" deben ser usados para las diferentes
codificaciones y transformaciones de Unicode transformations of Unicode /
ISO/IEC 10646, los valores "ISO-8859-1",
"ISO-8859-2", ... "ISO-8859-9" deben ser usados
por las partes de ISO 8859, y los valores "ISO-2022-JP",
"Shift_JIS", y "EUC-JP" deben ser usados para las
varias formas codificadas de JIS X-0208-1997. Los procesadores de XML pueden
reconocer otras codificaciones; es recomendado que los caracteres de
codificación sean registrados como charsets con la Internet
Assigned Numbers Authority [IANA],
otros diferentes a los listados, deben ser referidos usando sus nombres
registrados. Note que estos nombres registrados son definidos como no
sensibles a mayúsculas, así que los procesadores que deseen emparejar con
estos nombres lo deben hacer de una forma no dependiente de mayúsculas.
En la ausencia de información provista por un protocolo externo de
transporte(e.g. HTTP or MIME), es un error
presentar a la aplicación una entidad que ha declarado una codificación en
otra diferente a la nombrada en la declaración, también es un error que una
declaración ocurra en un lugar distinto al comienzo de una entidad externa,
o que para una entidad que no comienza con ninguna marca de orden de byte ni
con una declaración de codificación se use otra diferente a UTF-8. Note que
ya que ASCII es un subconjunto de UTF-8, las entidades ordinarias de ASCII
no necesitan estrictamente una declaración de codificación.
Es un error
fatal cuando un procesador de XML encuentra una entidad con una
codificación que no está preparado para manejar.
Ejemplos de declaraciones de codificación:
<?xml codificación='UTF-8'?>
<?xml codificación='EUC-JP'?> |
La tabla siguiente resume los contextos en los cuales las referencias a
caracter, referencias a entidades e invocaciones de entidades no procesadas
pueden aparecer y el comportamiento requerido de un procesador
de XML en cada caso. Las leyendas en la columna de la izquierda
describen el contexto de reconocimiento:
- Referencia en contenido
- una referencia en cualquier punto después del tag de
comienzo y antes del tag de
fin de un elemento ; corresponde al no terminal
content.
- Referencia en el valor de un atributo
- una referencia dentro del valor de un atributo en un tag de
comienzo, o un valor por defecto en una declaración
de atributo; corresponde al no terminal
AttValue.
- Ocurre como valor de atributo
- un
Nombre,
no una referencia, que aparece o bien como el color de un atributo que ha
sido declarado del tipo ENTITY, o como uno de los tokens
separados por espacios en el valor de un atributo que haya sido declarado
del tipo ENTITIES.
- Referencia en Valor de entidad
- una referencia dentro del valor
literal de entidad de una entidad parámetro o interna en la
declaración de la entidad; corresponde al no terminal
EntityValue.
- Referencia en el DTD
- Una referencia dentro del subconjunto interno o externo del DTD,
pero afuera de una
EntityValue
o AttValue.
Fuera del DTD, el caracter % no tiene ningún significado
especial: así, lo que sería considerado una entidad de parámetro dentro del
DTD, no es reconocido como marcación en el contenido.
Similarmente, los nombres de entidades sin procesar no son reconocidos
excepto cuando aparecen en el valor de un atributo apropiadamente declarado.
[Definición:] Una entidad es
Incluida cuando su texto
de reemplazo es traído y procesado, en lugar de la referencia misma,
como si fuese parte del documento en el lugar en que la referencia fue
reconocida. El texto de remplazo puede contener tanto datos
de caracter como (excepto en el caso de las entidades de parámetro) marcación,
lo cual debe ser reconocido en la forma usual , excepto que el texto de
remplazo de las entidades usadas para escapar delimitadores de marcación
(las entidades amp, lt, gt,
apos, quot) son siempre tratadas como datos. (La
cadena "AT&T;" se expande a "AT&T;" y
el ampersand restante no es reconocido como un delimitador de
entidad-referencia.) Una referencia a caracter es Incluida cuando el
caracter indicado es procesado en lugar de la referencia misma.
Cuando un procesador reconoce una referencia a una entidad procesada,
para poder validar
el documento, el procesador debe incluir
su texto de remplazo. Si la entidad es externa, y el procesador no está
intentando validar el documento XML, el procesador puede,
pero no tiene que, incluir el texto de remplazo de la entidad. Si un
procesador no validador no incluye el texto de remplazo, debe informar a la
aplicación que reconoció, pero no leyó la entidad.
Esta regla está basada en el reconocimiento de que la inclusión
automática provista por el mecanismo de entidades de SGML y XML,
primariamente diseñado para soportar modularidad, no es necesariamente
apropiado para otras aplicaciones, en particular, la navegación (Browsing)
de documentos. Un navegador, por ejemplo, cuando se encuentra una referencia
a una entidad externa procesada, puede escoger presentar una indicación
visual de la presencia de la entidad y traerla para desplegarla solamente
bajo demanda.
Las siguientes cosas están prohibidas, y constituyen errores fatales
:
- la aparición de una referencia a una entidad
no procesada.
- la aparición de una referencia a cualquier entidad de caracter o
general en un DTD excepto dentro de
EntityValue
o AttValue.
- una referencia a una entidad externa en un valor de atributo.
Cuando una referencia
a entidad aparece en el valor de un valor de atributo, o una referencia
a una entidad de parámetro aparece en un valor literal de entidad, su texto
de remplazo es procesado en lugar de la referencia misma como si fuera
parte del documento en el punto en que la referencia fue reconocida, excepto
por un caracter de comillas simples o dobles en el texto de remplazo siempre
es tratado como un caracter de datos normal y no va a terminar el literal.
Por ejemplo, lo siguiente está bien formado:
<!ENTITY % YN '"Yes"' >
<!ENTITY WhatHeSaid "He said &YN;" > |
mientras que esto no:
<!ENTITY EndAttr "27'" >
<element atributo='a-&EndAttr;> |
Cuando el nombre de una entidad
no procesada aparece como un token en el valor de un atributo declarado
de tipo ENTITY or ENTIDTIES, un procesador
validador debe informar a la aplicación de los identificadores system
y public
(si existen) para tanto la entidad como para sus notaciones
asociadas.
Cuando una referencia a una entidad general aparece en el EntityValue
en una declaración, ésta es pasada por alto y dejada tal como está.
Tal y como sucede con las entidades externas procesadas, las entidades
parámetro sólo necesitan ser Incluidas
si se está validado . Cuando una referencia a parámetro-entidad es
reconocida en el DTD y es incluida, su texto
de remplazo es ampliado por la adición de un caracter de espacio (#x20)
de comienzo y un espacio a continuación; La intención es restringir el texto
de remplazo de entidades parámetro para que contengan un número entero de
tokens gramaticales en el DTD.
Al discutir el tratamiento de las entidades internas, es útil distinguir
dos formas del valor de una entidad. [Definición:] El valor literal de la entidad es la
cadena entre comillas presente en la declaración de entidad, correspondiente
al no terminal EntityValue.
[Definición:] El texto de
remplazo es el contenido de la entidad, después del remplazo de
referencias a caracter y referencias parámetro-entidad.
El valor literal de entidad tal y como está dado en una declaración
interna (EntityValue)
puede contener referencias de caracter, de parámetro y generales. Tales
referencias deben estar contenidas enteramente dentro del valor literal de
la entidad. El texto de remplazo que es incluido
como es descrito arriba debe contener el texto de remplazo de
cualquier entidad de parámetro a la que se haga referencia, y debe contener
el caracter referido en lugar de las referencias a caracter en el valor
literal de la entidad; de cualquier manera, las referencias de entidad
general deben ser dejadas tal y como están, sin expandir. Por ejemplo, dadas
las siguientes declaraciones:
<!ENTITY % pub "Éditions Gallimard" >
<!ENTITY rights "All rights reserved" >
<!ENTITY book "La Peste: Albert Camus,
© 1947 %pub;. &rights;" > |
entonces, el texto de remplazo para la entidad "book" es:
La Peste: Albert Camus,
© 1947 Éditions Gallimard. &rights; |
La referencia general "&rights;" debe ser expandida a la
referencia cuando "&book;" aparezca en el contenido de un
documento o valor de atributo.
Estas simples reglas pueden tener complejas interacciones; para una
discusión detallada acerca de un ejemplo complejo, ver D. Expansión
de referencias a entidades y caracteres".
[Definición:] Las referencias a
entidades y caracteres pueden ser ambas usadas para escapar el
símbolo de menor que, el ampersand y otros delimitadores. Un conjunto de
entidades generales (amp, lt, gt,
apos, quot) está identificado para ese propósito.
Las referencias a caracteres numéricos también pueden ser usadas; estas son
expandidas inmediatamente cuando son reconocidas y deben ser tratadas como
datos de caracter, así que las referencias numéricas
"<" y "&" pueden ser usadas para
escapar < y & cuando estas ocurren en datos
de caracter.
Todos los procesadores de XML deben reconocer estas entidades bien si
están declaradas o no. Por
interoperabilidad, los documentos de XML válidos deben declarar estas
entidades, como con las demás, antes de usarlas. Si las entidades en
cuestión son declaradas, deben estar declaradas como entidades internas cuyo
texto de remplazo es el caracter sencillo escapado por la referencia o una
referencia a dicho caracter, como es mostrado más abajo.
<!ENTITY lt "&#60;">
<!ENTITY gt ">">
<!ENTITY amp "&#38;">
<!ENTITY apos "'">
<!ENTITY quot """>
|
Note que los caracteres < y & en las
declaraciones de "lt" y "amp" están doblemente
escapadas para alcanzar los requerimientos acerca de la buena formación de
remplazo de entidades.
[Definición:] Las
Notaciones identifican por nombre el formato de entidades
no procesadas, el formato de elementos que cargan un atributo notación,
o la aplicación para la cual está destinada una a instrucción
de proceso.
[Definición:] Las
declaraciones de notación proveen un nombre para la notación, para
uso en declaraciones de lista de atributo, en especificaciones de atributo,
y como identificador externo para la notación la cual puede permitir al
procesador de XML o sus clientes localizar una aplicación ayudante capaz de
procesar el tipo de datos en la notación dada.
| Declaraciones de notación |
|
|
Los procesadores de XML deben proveer la aplicación con el nombre e
identificador externo de cualquier notación declarada y referida en un valor
de atributo, definición de atributo o declaración de entidad. También pueden
adicionalmente resolver el identificador externo hasta llegar a un
identificador de sistema -system
identifier-, nombre de archivo, u otra información necesaria para
permitir que la aplicación llame un procesador para datos en la notación
descrita. (No es un error que un documento XML declare y haga referencia a
notaciones para las cuales no existan aplicaciones manejadoras específicas
en el sistema en el que el procesador o aplicación están corriendo.)
[Definición:] La entidad
documento sirve como la raíz del árbol de entidades y como punto de
partida para el procesador
de XML . Esta especificación no dice como la entidad documento
debe ser localizada por el procesador; contrario a las demás entidades, la
entidad documento no tiene nombre y puede aparecer en el flujo de entrada
del procesador sin ninguna identificación.
Los procesadores
de XML caen en dos clases:Validadores y No-Validadores.
Los procesadores, los Validadores y los no-Validadores, deben reportar
violaciones de las restricciones de buena-formación en el contenido de la entidad
documento y cualquier otra entidades
procesada que lean.
[Definición:] Los
procesadores Validadores deben reportar violaciones de las
restricciones expresadas por las declaraciones en el DTD,
y fallas con respecto a las restricciones de validez dadas en esta
especificación. Para lograr esto, los procesadores validadores de XML
deben leer y procesar el DTD totalmente y todas las entidades externas
procesadas referenciadas en el documento.
Los procesadores no validadores solamente están obligados a revisar la entidad
documento, incluido el DTD en su totalidad, para garantizar su buena
formación. [Definición:] Aunque
no es requerido que revisen el documento en términos de validez, si se
requiere que procesen todas las declaraciones que lean en el
subconjunto interno del DTD y en cualquier entidad de parámetro que lean,
hasta la primera referencia a una entidad parámetro que no lean;
esto es decir que deben utilizar estas declaraciones para normalizar
valores de atributos, incluirel
texto de reemplazo de entidades internas, y suplir valores
por defecto de atributos . El procesador no debe procesar
las
declaraciones de entidad o declaraciones
de lista de atributos encontradas después de una referencia a una
entidad parámetro que no es leída, ya que la entidad puede haber contenido
declaraciones que sobre escribieran otras (overriding).
El comportamiento de un procesador Validador de XML es altamente
predecible; debe leer cada pieza del documento y reportar toda violación a
la buena formación o validez. Es requerido menos de un procesador no
validador; éste no tiene que leer ninguna otra parte del documento diferente
a la entidad documento. Esto tiene dos efectos que pueden ser importantes
para usuarios de procesadores de XML:
- Algunos errores de buena formación, específicamente aquellos que
requieren la lectura de entidades externas, pueden no ser detectados por
un procesador no validador. Algunos ejemplos incluyen las restricciones
tituladas Entidad
declarada, Entidad
procesada, y No
Recursión, al igual que algunos casos descritos como Prohibidos
en "4.4 Tratamiento
del procesador de XML de Entidades y Referencias".
- La información pasada del procesador a la aplicación puede variar,
dependiendo de si el procesador lee parameteros y entidades externas. Por
ejemplo, un procesador no validador puede no normalizar
valores de atributo, incluir
el texto de remplazo de entidades internas, o suplir valores
de atributo por defecto, donde hacerlo depende de haber leído
declaraciones en entidades externas o de parámetro.
Para maximizar la confiabilidad en la interoperabilidad entre diferentes
procesadores de XML, las aplicaciones que usan procesadores no validadores
no deben recurrir a ningún comportamiento no requerido en dichos
procesadores. Las aplicaciones que requieren facilidades como el uso de
atributos por defecto o entidades internas que han sido declaradas en
entidades externas deben usar procesadores de XML validadores.
La gramática formal de XML está dada en esta especificación usando una
forma simple de la notación Extended Backus-Naur Form (EBNF). Cada símbolo
en la gramática define un símbolo, en la forma
Los símbolos están escritos con una letra mayúscula inicial si están
definidos por una expresión regular, o por una minúscula de lo contrario.
Las cadenas literales están entre comillas.
Dentro de la expresión en el lado derecho de una regla, las siguientes
expresiones son usadas para emparejar cadenas de uno o más caracteres:
#xN
- donde
N es un entero hexadecimal, la expresión empareja
el caracter en ISO/IEC 10646 cuyo valor canónico (UCS-4), cuando es
interpretado como un número binario sin signo, tiene el valor indicado. El
número de ceros al comienzo en la forma #xN es
insignificante; el número de ceros al comienzo en el correspondiente valor
de código está gobernado por la codificación de caracter en uso y no tiene
significado para XML.
[a-zA-Z], [#xN-#xN]
- se empareja con cualquier caracter
con un valor en el rango indicado (inclusive).
[^a-z], [^#xN-#xN]
- se empareja con un caracter
con un valor fuera del rango indicado.
[^abc], [^#xN#xN#xN]
- se empareja con cualquier caracter
con un valor que no esté dentro de los caracteres dados.
"string"
- se empareja con una cadena literal emparejandose
con aquello dado dentro de las comillas dobles.
'string'
- se empareja con una cadena literal emparejando
con aquello dado dentro de las comillas sencillas.
Estos símbolos pueden ser combinados para emparejar patrones más
complejos como se muestra a continuación donde A y
B representan expresiones simples:
- (
expression)
expression es tratado como una unidad y puede ser
combinado como se describe en esta lista.
A?
- se empareja con
A o nada; opcional A.
A B
- se empareja con
A seguido por B.
A | B
- se empareja con
A o B pero no con ambos.
A - B
- se empareja con cualquier cadena que se empareje con
A
pero no con V B.
A+
- se empareja con una o más ocurrencias de
A.
A*
- se empareja con cero o más ocurrencias de
A.
Otras notaciones usadas en las producciones son:
/* ... */
- comentario
[ wfc: ... ]
- Restricción de buena-formación; ésto identifica por nombre una
restricción sobre documentos bien
formados asociada a una producción.
[ vc: ... ]
- Restricción de Validez; esto identifica por nombre una restricción
sobre documentos válidos
asociada a una producción.
Apéndices
- Por su naturaleza se mantienen en inglés.
- IANA
- (Internet Assigned Numbers Authority) Official Nombres for
Caracter Sets, ed. Keld Simonsen et al. See ftp://ftp.isi.edu/in-notes/iana/assignments/caracter-sets.
- IETF RFC 1766
- IETF (Internet Engineering Task Force). RFC 1766: Tags for the
Identification of Languages, ed. H. Alvestrand. 1995.
- ISO 639
- (International Organization for Standardization). ISO 639:1988
(E). Code for the representation of nombres of languages. [Geneva]:
International Organization for Standardization, 1988.
- ISO 3166
- (International Organization for Standardization). ISO 3166-1:1997
(E). Codes for the representation of nombres of countries and their
subdivisions -- Part 1: Country codes [Geneva]: International
Organization for Standardization, 1997.
- ISO/IEC 10646
- ISO (International Organization for Standardization). ISO/IEC
10646-1993 (E). Information technology -- Universal Multiple-Octet Coded
Caracter Set (UCS) -- Part 1: Architecture and Basic Multilingual
Plane. [Geneva]: International Organization for Standardization, 1993
(plus amendments AM 1 through AM 7).
- Unicode
- The Unicode Consortium. The Unicode Standard, Version 2.0.
Reading, Mass.: Addison-Wesley Developers Press, 1996.
- Aho/Ullman
- Aho, Alfred V., Ravi Sethi, and Jeffrey D. Ullman. Compilers:
Principles, Techniques, and Tools. Reading: Addison-Wesley, 1986,
rpt. corr. 1988.
- Berners-Lee et al.
- Berners-Lee, T., R. Fielding, and L. Masinter. Uniform Resource
Identifiers (URI): Generic Syntax and Semantics. 1997. (Work in
progress; see updates to RFC1738.)
- Brüggemann-Klein
- Brüggemann-Klein, Anne. Regular Expressions into Finite
Automata. Extended abstract in I. Simon, Hrsg., LATIN 1992, S. 97-98.
Springer-Verlag, Berlin 1992. Full Version in Theoretical Computer Science
120: 197-213, 1993.
-
- Brüggemann-Klein and Wood
- Brüggemann-Klein, Anne, and Derick Wood. Deterministic Regular
Languages. Universität Freiburg, Institut für Informatik, Bericht 38,
Oktober 1991.
- Clark
- James Clark. Comparison of SGML and XML. See http://www.w3.org/TR/NOTE-sgml-xml-971215.
- IETF RFC1738
- IETF (Internet Engineering Task Force). RFC 1738: Uniform Resource
Locators (URL), ed. T. Berners-Lee, L. Masinter, M. McCahill. 1994.
- IETF RFC1808
- IETF (Internet Engineering Task Force). RFC 1808: Relative Uniform
Resource Locators, ed. R. Fielding. 1995.
- IETF RFC2141
- IETF (Internet Engineering Task Force). RFC 2141: URN Syntax,
ed. R. Moats. 1997.
- ISO 8879
- ISO (International Organization for Standardization). ISO
8879:1986(E). Information processing -- Text and Office Systems --
Standard Generalized Markup Language (SGML). First edition --
1986-10-15. [Geneva]: International Organization for Standardization,
1986.
- ISO/IEC 10744
- ISO (International Organization for Standardization). ISO/IEC
10744-1992 (E). Information technology -- Hypermedia/Time-based
Structuring Language (HyTime). [Geneva]: International Organization
for Standardization, 1992. Extended Facilities Annexe. [Geneva]:
International Organization for Standardization, 1996.
Siguiendo las características definidas en el estándar Unicode, los
caracteres son clasificados como caracteres de base (entre otros, estos
contienen los caracteres alfabéticos del alfabeto latino, sin diacríticos),
Caracteres ideográficos, y caracteres de combinación (entre otros, esta
clase contiene la mayoría de diacríticos); Estas clases se combinan para
formar la clase de las letras. Los dígitos y extensores son también
distinguidos.
| Caracteres |
| [84] |
Letter |
::=
|
BaseChar
| Ideographic |
| [85] |
BaseChar |
::=
|
[#x0041-#x005A]
| [#x0061-#x007A] | [#x00C0-#x00D6]
| [#x00D8-#x00F6] | [#x00F8-#x00FF]
| [#x0100-#x0131] | [#x0134-#x013E]
| [#x0141-#x0148] | [#x014A-#x017E]
| [#x0180-#x01C3] | [#x01CD-#x01F0]
| [#x01F4-#x01F5] | [#x01FA-#x0217]
| [#x0250-#x02A8] | #x02BB-#x02C1] |#x0386
| [#x0388-#x038A] | #x038C | [#x038E-#x03A1]
| [#x03A3-#x03CE] | [#x03D0-#x03D6] | #x03DA
| #x03DC | #x03DE | #x03E0 | [#x03E2-#x03F3]
| [#x0401-#x040C] | [#x040E-#x044F]
| [#x0451-#x045C] | [#x045E-#x0481]
| [#x0490-#x04C4] | [#x04C7-#x04C8]
| [#x04CB-#x04CC] | [#x04D0-#x04EB]
| [#x04EE-#x04F5] | [#x04F8-#x04F9]
| [#x0531-#x0556] | #x0559 | [#x0561-#x0586]
| [#x05D0-#x05EA] | [#x05F0-#x05F2]
| [#x0621-#x063A] | [#x0641-#x064A]
| [#x0671-#x06B7] | [#x06BA-#x06BE]
| [#x06C0-#x06CE] | [#x06D0-#x06D3] | #x06D5
| [#x06E5-#x06E6] | [#x0905-#x0939] | #x093D
| [#x0958-#x0961] | #x0985-#x098C]
| [#x098F-#x0990] | [#x0993-#x09A8]
| [#x09AA-#x09B0] | #x09B2 | [#x09B6-#x09B9]
| [#x09DC-#x09DD] | [#x09DF-#x09E1]
| [#x09F0-#x09F1] | [#x0A05-#x0A0A]
| [#x0A0F-#x0A10] | [#x0A13-#x0A28]
| [#x0A2A-#x0A30] | [#x0A32-#x0A33]
| [#x0A35-#x0A36] | [x0A38-#x0A39]
| [#x0A59-#x0A5C] | #x0A5E | [#x0A72-#x0A74]
| [#x0A85-#x0A8B] | #x0A8D | [#x0A8F-#x0A91]
| [#x0A93-#x0AA8] [#x0AAA-#x0AB0]
| [#x0AB2-#x0AB3] | [#x0AB5-#x0AB9] | #x0ABD
| #x0AE0 | [#x0B05-#x0B0C] | [#x0B0F-#x0B10]
| [#x0B13-#x0B28] | [#x0B2A-#x0B30]
| [#x0B32-#x0B33] | [#x0B36-#x0B39] | #x0B3D
| [#x0B5C-#x0B5D] | [#x0B5F-#x0B61]
| [#x0B85-#x0B8A] | [#x0B8E-#x0B90]
| [#x0B92-#x0B95] [x0B99-#x0B9A] | #x0B9C
| [#x0B9E-#x0B9F] | [#x0BA3-#x0BA4]
| [#x0BA8-#x0BAA] | [#x0BAE-#x0BB5]
| [#x0BB7-#x0BB9] | [#x0C05-#x0C0C]
| [#x0C0E-#x0C10] | [#x0C12-#x0C28] |[#x0C2A-#x0C33]
| [#x0C35-#x0C39] | [#x0C60-#x0C61]
| [#x0C85-#x0C8C] | [#x0C8E-#x0C90]
| [#x0C92-#x0CA8] | #x0CAA-#x0CB3]
| [#x0CB5-#x0CB9] | #x0CDE | [#x0CE0-#x0CE1]
| [#x0D05-#x0D0C] | [#x0D0E-#x0D10]
| [#x0D12-#x0D28] | [#x0D2A#0D39]
| [#x0D60-#x0D61] | [#x0E01-#x0E2E] | #x0E30
| [#x0E32-#x0E33] | [#x0E40-#x0E45]
| [#x0E81-#x0E2 | #x0E84 | [#x0E87-#x0E88]
| #0E8A | #x0E8D | [#x0E94-#x0E97]
|[#x0E99-#x0E9F] | [#x0EA1-#x0EA3] | #x0EA5
| #x0EA7 | [#x0EAA-#x0EAB] | [#x0EAD-#x0EAE]
| #x0EB0 | [#x0EB2-#x0EB3] | #x0EBD
| [#x0EC0-#x0EC4] | [#x0F40-#x0F47]
| [#x09-#x0F69] | [#x10A0-#x10C5]
| [#x10D0-#x10F6] | #x1100 | [#x1102-#x1103]
[#x1105-#x1107] | #x1109 | [#x110B-#x110C]
| [#x110E-#x1112] | #x113C | #x113E | #x1140
| #x114C | #x114E | #x1150 | [#x1154-#x1155]
| #x1159 | [#x115F-#x1161] | #x1163 | #x1165
| #x1167 | #x1169 | [#x116D-#x116E]
| [#x1172-#x1173] | #x1175 | #x119E | #x11A8
| #x11AB | [#x11AE-#x11AF] | [#x11B7-#x11B8]
| #x11BA | [#x11BC-#x11C2] | #x11EB | #x11F0
| #x11F9 | [#x1E00-#x1E9B] | [#x1EA0-#x1EF9]
| #x1F00-#x1F15] | [#x1F18-#x1F1D]
| [#x1F20-#x1F45] | [#x1F48-#x1F4D]
| [#x1F50-#x1F57] | #x1F59 | #x1F5B | #x1F5D
| [#x1F5F-#x1F7D] | [#x1F80-#x1FB4]
| [#x1FB6-#x1FBC] | #x1FBE | [#x1FC2-#x1FC4]
| [#x1FC6-#x1FCC] | [#x1FD0-#x1FD3]
| [#x1FD6-#x1FDB] | [#x1FE0-#x1FEC]
| [x1FF2-#x1FF4] | [#x1FF6-#x1FFC] | #x2126
| [#x212A-#x212B] | #212E | [#x2180-#x2182]
| #x3041-#3094] | [#x30A1-#x3FA] | [#x3105-#x3C]
| [#xAC00-#xD7A3] |
| [86] |
Ideographic |
::=
|
[#x4E00-#x9FA5] | #x3007
| [#x3021-#x3029] |
| [87] |
CombiningChar |
::=
|
[#x0300-#x0345]
| #x0360-#x0361] | [#x0483-#x0486]
| [#x0591-#x05A1] | [#x05A3-#x05B9]
| [#x05BB-#x05BD] | #x05BF | [#x05C1-#x05C2]
| #x05C4 | [#x064B-#x0652] | #x0670
| [#x06D6-#x06DC] | [#x06DD-#x06DF]
| [#x06E0-#x06E4] | [#x06E7-#x06E8]
| [#x06EA-#x06ED] | [#x0901-#x0903] | #x093C
| [#x093E-#x094C] | #x094D | [#x0951-#0954]
| [#x0962-#x0963] | [#x0981-#x0983] | #x09BC
| #x09BE | #x09BF | [#x09C0-#x09C4]
| [#x09C7-#x09C8] | [#x09CB-#x09CD] | #x09D7
| [#x09E2-#x09E3] | #x0A02 | #x0A3C | #x0A3E
| #x0A3F | [#x0A40-#x0A42] | [#x0A47-#x0A48]
| [#x0A4B-#x0A4D] | [#x0A70-#x0A71]
| [#x0A81-#x0A83] | #x0ABC | [#x0ABE-#x0AC5]
| [#x0AC7-#x0AC9] | [#x0ACB-#x0ACD]
| [#x0B01-#x0B03] | #x0B3C | [#x0B3E-#x0B43]
| [#x0B47-#x0B48] | [#x0B4B-#x0B4D] |[#x0B56-#x0B57]
| [#x0B82-#x0B83] | [#x0BBE-#x0BC2]
| [#x0BC6-#x0BC8] | [#x0BCA-#x0BCD] | x0BD7
| [#x0C01-#x0C03] | [#x0C3E-#x0C44]
| [#x0C46-#x0C48] | [#x0C4A-#x0C4D]
| [#x0C55-#x0C56] | [#x0C82-#x0C83]
| [#x0CBE-#x0CC4] | [#x0CC6-#x0CC8]
| [#x0CCA-#x0CCD] | [#x0CD5-#x0CD6]
| [#x0D02-#x0D03] | [#x0D3E-#x0D43]
| [#x0D46-#x0D48] | [#x0D4A-#x0D4D] | #x0D57
| #x0E31 | [#x0E34-#x0E3A] | [#x0E47-#x0E4E]
| #x0EB1 | [#x0EB4-#x0EB9] | [#x0EBB-#x0EBC]
| [#x0EC8-#x0ECD] | [#x0F18-#x0F19] | #x0F35
| #x0F37 | #x0F39 | #x0F3E | #x0F3F
| [#x0F71-#x0F84] | [#x0F86-#x0F8B]
| [#x0F90-#x0F95] | #x0F97 | [#x0F99-#x0FAD]
| [#x0FB1-#x0FB7] | #x0FB9 | [#x20D0-#x20DC]
| #x20E1 | [#x302A-#x302F] | #x3099 | #x309A
|
| [88] |
Digit |
::=
|
[#x0030-#x0039]| [#x0660-#x0669]
| [#x06F0-#x06F9] | [#x0966-#x096F]
| [#x09E6-#x09EF] | [#x0A66-#x0A6F]
| [#x0AE6-#x0AEF] | [#x0B66-#x0B6F]
| [#x0BE7-#x0BEF] | [#x0C66-#x0C6F]
| [#x0CE6-#x0CEF] | [#x0D66-#x0D6F]
| [#x0E50-#x0E59] | [#x0ED0-#x0ED9]
| [#x0F20-#x0F29] |
| [89] |
Extender |
::=
|
#x00B7 | #x02D0
| #x02D1 | #x0387 | #x0640 | #x0E46
| x0EC6 #x3005 |[#x3031-#x3035] | #x309D-#x309E]
| [#x30FC-#x30F]
| |
Los caracteres aquí definidos pueden ser derivados de la base de datos de
caracteres Unicode de la siguiente manera:
- Los caracteres de comienzo de nombre deben tener una de las categorías
Ll, Lu, Lo, Lt, Nl.
- Los Caracteres de nombre diferentes a los nombres de comienzo de
caracteres deben tener una de las categorías Mc, Me, Mn, Lm, or Nd.
- Caracteres el área de compatibilidad (i.e. con código de caracter
mayor que #xF900 y menor que #xFFFE) no están permitidos en nombres XML.
- Los Caracteres que tienen una descomposición de fuente o
compatibilidad (i.e. aquellos con un "tag de compatibilidad de formato" en
el campo 5 de la base de datos -- marcado por el campo 5 comenzando con un
"<") no son permitidos.
- Los siguientes caracteres son tratados como caracteres de comienzo de
nombre en lugar de hacerlo como caracteres de nombre porque el archivo de
propiedades los clasifica como alfabéticos: [#x02BB-#x02C1], #x0559,
#x06E5, #x06E6.
- Los caracteres #x20DD-#x20E0 son excluidos (de acuerdo con Unicode,
secció 5.14).
- El Caracter #x00B7 es clasificado como un extenso, debido a que la
lista de propiedades así lo identifica.
- El Caracter #x0387 es añadido como un caracter de nombre, porque
#x00B7 es su equivalente canónico
- Los Caracteres ':' y '_' son permitidos como caracteres de comienzo de
nombre.
- Los Caracteres '-' y '.' son permitidos como caracteres de nombre.
XML está diseñado para ser un subconjunto de SGML, en cuanto todo
documento XML válido
debe ser también un documento SGML conforme. Para una comparación detallada
de las restricciones adicionales que XML impone a sus documentos, ver [Clark].
Este apéndice contiene algunos ejemplos ilustrando la secuencia de
reconocimiento y expansión de referencias a entidad y caracter, tal y como
se especifica en "4.4 Tratamiento
de entidades y referencias por parte del procesador de XML".
Si el DTD contiene la declaración
<!ENTITY ejemplo "<p>An ampersand (&#38;) may be escaped
numerically (&#38;#38;) or with a general entity
(&amp;).</p>" >
|
entonces el procesador de XML reconocerá las referencias a caracter
cuando procese la declaración, y las resolverá antes de guardar la siguiente
cadena como el valor de la entidad "ejemplo":
<p>Un ampersand (&) puede ser escapada
numericamente (&#38;) o con una entidad general
(&amp;).</p>
|
Una referencia en el documento a "&ejemplo;" causará que
el texto sea reprocesado, al tiempo que los tags de comienzo y fin del
elemento "p" sean reconocidas y las tres referencias sean
reconocidas y expandidas, resultando en un elemento "p" con el
siguiente contenido (todo datos, no delimitadores ni marcas):
Un ampersand (&) puede ser escapado
numéricamente (&) o con una entidad general
(&).
|
Un ejemplo más complejo ilustrará las reglas y sus efectos completamente.
En el siguiente ejemplo, los números de línea son sólo ilustrativos.
1 <?xml version='1.0'?>
2 <!DOCTYPE test [
3 <!ELEMENT test (#PCDATA) >
4 <!ENTITY % xx '%zz;'>
5 <!ENTITY % zz '<!ENTITY tricky "error-prone" >' >
6 %xx;
7 ]>
8 <test>This sample shows a &tricky; method.</test>
|
Esto produce lo siguiente:
- En la línea 4, el caracter 37 es extendido inmediatamente, y la
entidad parámetro "
xx" es guardada en la tabla de símbolos
con el valor "%zz;". Ya que el texto de remplazo no es
reprocesado la referencia a la entidad parámetro "zz" no es
reconocida. (Y sería un error si lo fuera, ya que "zz" no ha
sido aún declarada.)
- En la línea 5, la referencia a caracter "
<" es
expandida inmediatamente y la entidad parámetro "zz" es
guardada con el texto de remplazo "<!ENTITY tricky "error-prone"
>", lo cual es una declaración de entidad bien formada.
- En la línea 6, la referencia "
xx" es reconocida, y el
texto de remplazo de "xx" (nombrado "%zz;") es
procesado. La referencia a "zz" es reconocida en su momento,
y su texto de remplazo ("<!ENTITY tricky "error-prone"
>") es procesado. La entidad general "tricky" ha
sido ahora declarada, con el texto de remplazo "error-prone".
- en la línea 8, la referencia a la entidad general
"
tricky" es reconocida, y es expandida, así que el contenido
completo del elemento "test" es la cadena auto-descriptiva (y
no gramatical) This sample shows a error-prone method.
Por
compatibilidad, es requerido que los modelos de contenido de las
declaraciones de tipo de elemento sean determinísticos.
SGML requiere modelos de contenido determinísticos (los llama "no
ambiguos"); los procesadores de XML construidos usando sistemas SGML pueden
reportar los modelos de contenido no determinísticos como errores.
Por ejemplo, el modelo de contenido ((b, c) | (b, d)) es no
determinístico pues dada una b inicial un procesador no puede
saber cual b en el modelo de contenido está siendo emparejada
sin mirar que caracter sigue a la b. En este caso, las dos
referencias a B pueden ser colapsadas en una sola referencia, haciendo que
el modelo se lea (b, (c | d)). Ahora b claramente
se empareja sólo con un nombre sencillo en el modelo de contenido. El
procesador no necesita mirar más allá para ver que sigue; tanto
c como d serían aceptados.
Más formalmente: un autómata de estados finitos puede ser construido a
partir del modelo de contenido usando algoritmos estándar, e.g. algoritmo
3.5 en la sección 3.9 de Aho, Sethi, y Ullman [Aho/Ullman].
En muchos de dicho algoritmos, un conjunto es construido por cada posición
en la expresión regular (i.e., cada nodo hoja en el árbol de sintaxis para
la expresión regular); Si alguna posición tiene un conjunto en el cual más
de una posición siguiente es marcada con el mismo nombre de tipo de
elemento, entonces el modelo de contenido es un error y puede ser reportado
como tal.
Existen algoritmos que permiten la reducción automática de muchos, pero
no todos, los modelos no determinísticos a equivalentes determinísticos; ver
Brüggemann-Klein 1991 [Brüggemann-Klein].
La codificación de la declaración XML funciona como una leyenda interna
en cada entidad, indicando cual codificación de caracter está en uso. Antes
de que el procesador de XML pueda leer la leyenda interna, aparentemente
tiene que saber cual codificación de caracter está en uso -- lo cual es
precisamente lo que la leyenda está intentando indicar. En el caso general
esta es una situación desesperada. No es enteramente desesperada en XML,
pues XML limita el caso general en dos formas: cada implementación se
presume soporta sólo un conjunto finito de codificaciones de caracter, y la
declaración de codificación de XML está restringida en posición y orden con
el fin de hacer posible la autodetección de la codificación de caracter en
uso en cada entidad en casos normales. Además, en muchos casos otras fuentes
de información diferentes al flujo de datos de XML mismo están disponibles.
Dos casos son distinguibles, dependiendo de si existe o no una información
externa la cual es presentada al procesador. Consideramos el primer caso
primero.
Ya que cada entidad XML que no esté en formato UTF-8 o UTF-16
debe comenzar con una declaración de codificación XML, en la cual
los primeros caracteres deben ser '<?xml', cualquier
procesador conforme puede detectar después de dos a cuatro octetos de
entrada, cual de los siguientes casos aplica. Al leer esta lista, puede ser
útil saber que en UCS-4, '<' es "#x0000003C" y '?' es
"#x0000003F", y la marca de orden de byte requerida para flujos
de datos en UTG-16 es "#xFEFF".
00 00 00 3C: UCS-4, máquinas 'big-endian' (1234 order)
3C 00 00 00: UCS-4, máquinas 'little-endian' (4321 order)
00 00 3C 00: UCS-4, orden de octeto inusual (2143)
00 3C 00 00: UCS-4, orden de octeto inusual (3412)
FE FF: UTF-16, big-endian
FF FE: UTF-16, little-endian
00 3C 00 3F: UTF-16, big-endian, sin marca de orden de
bytes (y por tanto, estrictamente hablando, un error)
3C 00 3F 00: UTF-16, little-endian, sin marca de orden de
bytes (y por tanto, estrictamente hablando, un error)
3C 3F 78 6D: UTF-8, ISO 646, ASCII, algunas partes de ISO
8859, Shift-JIS, EUC, o cualquier otra codificación de 7-bit, 8-bit, o
ancho mezclado que asegure que los caracteres de ASCII tienen sus
posiciones normales, ancho, y valores; las declaraciones de codificación
actuales deben ser leídas para detectar cual de estos aplica, pero ya que
todas estas codificaciones usan los mismos patrones de bits para los
caracteres ASCII, la declaración de codificación misma puede ser leída
confiablemente
4C 6F A7 94: EBCDIC (en algún sabor; la declaración de
codificación completa debe ser leída para poder determinar cuál código de
página está en uso)
- otros: UTF-8 sin una declaración de codificación, o de lo contrario el
flujo de datos está corrupto, fragmentado o encerrado en alguna envoltura
de algún tipo
Este nivel de auto-detección es suficiente para leer la declaración de
codificación y procesar el identificador de codificación de caracter, el
cual es necesario para distinguir los miembros individuales de cada familia
de codificaciones (e.g. para distinguir UTF-8 de 8859, y las diferentes
partes de 8859, o distinguir la página específica de EBCDIC en uso, etc).
Dado que el contenido de la declaración de codificación declaración está
restringida a caracteres ASCII, un procesador puede confiablemente la
declaración de codificación entera tan pronto como se detecta cual familia
de codificaciones está en uso. Dado que en la práctica, todas las
codificaciones de caracter ampliamente usadas caen en alguna de las
categorías de arriba, la declaración de codificación permite la marcación
razonablemente confiable de la declaración de codificación, aun cuando
fuentes externas de información en los niveles de sistema operacional y de
protocolo de transporte no sean confiables.
Una vez el procesador ha detectado la codificación de caracter en uso,
puede actuar apropiadamente, bien invocando una rutina separada para cada
caso, o llamando la función de conversión on cada caracter de la entrada.
Como todo sistema de auto-marcación, la XML declaración de codificación
no funcionará si algún software cambia el conjunto de caracteres de la
entidad o la codificación de la entidad sin renovar la declaración de
codificación. Los implementadores de las rutinas de codificación de
caracteres deben tener cuidado de asegurar la precisión de la información
interna y externa usada en la entidad.
El segundo caso posible ocurre cuando la entidad de XML está acompañada
por información de codificación, como es el caso de 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 manejar conflictos debe estar especificado como parte de un protocolo
de un nivel más alto usado para servir XML. Las reglas para la prioridad
relativa de la leyenda interna y la leyenda de MIME-type en un encabezado
externo, por ejemplo, deben ser parte del documento de RFC que define los
tipos MIME text/xml y application/xml. En los intereses de la
interoperabilidad, las siguientes reglas son recomendadas.
- Si una entidad XML está en un archivo, la marca de orden de byte y la
instrucción de declaración de codificación son usadas (si están presentes)
para determinar la codificación de caracter. Todas las demás heurísticas y
fuentes de información son dadas sólo para recuperación de errores.
- Si una entidad de XML es entregada con un tipo MIME text/xml, entonces
el parámetro
charset en el tipo MIME determina el método de
codificación de caracter; Todas las demás heurísticas y fuentes de
información están dadas sólo para recuperación de errores.
- Si una entidad XML es entregada con un tipo MIME application/xml,
entonces la marca de orden de byte y la instrucción son usadas (si están
presentes) para determinar la codificación de caracter. Todas las demás
heurísticas y fuentes de información están dadas sólo para recuperación de
errores.
Estas reglas aplican sólo en la ausencia de una documentación a nivel de
protocolo; en particular cuando los tipos MIME text/xml y application/xml
están definidos, las recomendaciones del documento RFC relevante tienen
precedencia sobre estas reglas.
Esta especificación fue preparada y aprobada para publicación por el
grupo de trabajo de XML de la W3C (EG). La aprobación de la especificación
por parte del WG no implica necesariamente que todos sus miembros votaron
por su aprobación. Los actuales y anteriores miembros del WG son:
Jon Bosak, Sun (Chair); James Clark (Technical Lead); Tim Bray,
Textuality and Netscape (XML Co-editor); Jean Paoli, Microsoft (XML
Co-editor); C. M. Sperberg-McQueen, U. of Ill. (XML Co-editor); Dan
Connolly, W3C (W3C Liaison); Paula Angerstein, Texcel; Steve DeRose, INSO;
Dave Hollander, HP; Eliot Kimber, ISOGEN; Eve Maler, ArborText; Tom
Magliery, NCSA; Murray Maloney, Muzmo and Grif; Makoto Murata, Fuji Xerox
Information Systems; Joel Nava, Adobe; Conleth O'Connell, Vignette; Peter
Sharpe, SoftQuad; John Tigue, DataChannel
Traducciones: