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 |
|
|
Traducciones: