El
Lenguaje Extensible de Marcas (XML) es un subconjunto de SGML, que
se describe completamente en este documento. Sus objetivos son
habilitar el SGML genérico para que pueda ser servido, recibido y
procesado en la Web de la manera que no es posible con HTML. XML
ha sido diseñado para facilitar la implementación e
interoperatividad con SGML y HTML.
Extensible Markup Language (XML) 1.0
El
Lenguaje Extensible de Marcas, abreviado XML, describe una clase
de objetos de datos llamados
documentos
XML y describe parcialmente el comportamiento de los programas
de computadora que los procesan. XML es un "perfil de
aplicación" o una forma restringida de SGML, el Lenguaje
Estándar Generalizado de Marcación
[ISO
8879]. Por construcción, los documentos XML son documentos
SGML conformados.
Los
documentos XML están compuestos por unidades de almacenamiento
llamadas
entidades,
que contienen tanto datos analizados como no analizados. Los datos
analizados están compuestos de
caracteres,
algunos de los cuales, de la forma
datos
carácter, y otros de la forma
marca.
Las marcas codifican una descripción de la estructura de
almacenamiento del documento y su estructura lógica. XML
proporciona un mecanismo para imponer restricciones al
almacenamiento y a la estructura lógica.
Se
utiliza un módulo software llamado procesador XML para leer
documentos XML y proporcionar acceso a su contenido y estructura. Se
asume que un procesador XML hace su trabajo dentro de otro
módulo, llamado aplicación. Esta especificación describe el
comportamiento requerido de un procesador XML en términos de
cómo leer datos XML y la información que debe proporcionar a la
aplicación.
XML
fue desarrollado por un Grupo de Trabajo XML (originalmente
conocido como "SGML Editorial Review Board") formado
bajo los auspicios del Consorcio World Wide Web (W3C), en 1996.
Fue presidido por Jon Bosak de Sun Microsystems con la
participación activa de un Grupo Especial de Interés en XML
(previamente conocido como Grupo de Trabajo SGML) también
organizado en el W3C. Los miembros del Grupo de Trabajo XML se
especifican en un apéndice. Dan Connolly sirvió como contacto
entre el GT y el W3C.
Los
objetivos de diseño de XML son:
-
XML
debe ser directamente utilizable sobre Internet.
-
XML
debe soportar una amplia variedad de aplicaciones.
-
XML
debe ser compatible con SGML.
-
Debe
ser fácil la escritura de programas que procesen documentos
XML.
-
El
número de características opcionales en XML debe ser
absolutamente mínima, idealmente cero.
-
Los
documentos XML deben ser legibles por humanos 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ácilmente creables.
-
La
concisión en las marcas XML es de mínima importancia.
Esta
especificación, junto con los estándares asociados (Unicode e
ISO/IEC 10646 para caracteres, Internet RFC 1766 para
identificación de lenguajes, ISO 639 para códigos de nombres de
lenguajes, e ISO 3166 para códigos de nombres de países),
proporciona toda la información necesaria para entender la
Versión 1.0 de XML y construir programas de computador que los
procesen.
Esta
versión de la especificación puede ser distribuida libremente,
siempre y cuando se mantengan intactos todos los textos y
términos legales.
La
terminología utilizada para describir los documentos XML esta
definida en el cuerpo de esta especificación. Los términos
definidos en la siguiente lista son utilizados en la construcción
de esas definiciones y en la descripción de las acciones del
procesador XML:
- poder
- La conformación
de documentos y los procesadores de XML pueden permitirlo,
pero no requieren ser soportados tal y como se describen.
- deber
- La conformación de documentos y los
procesadores de XML deben soportarlo tal y como se describe,
de otro modo son erróneos.
- error
- Una violación
de las reglas de esta especificación, los resultados están
indefinidos. Los programas conformadores deberían detectar e
informar acerca de los errores y recuperarse de ellos.
- error fatal
- Un error que
debe detectar un
procesador
XML e informar acerca de él a la aplicación. Tras
encontrar un error fatal, el procesador tiene que continuar
procesando los datos para buscar otros posibles errores y
debería de informar de los errores a la aplicación. Para
soportar la corrección de errores, el procesador debería
hacer que los datos no procesados del documento (con datos
carácter y marcas) sean accesibles a la aplicación. Una vez
que se detecta un error fatal, el procesador debe continuar el
procesado normalmente (p.e. no debe continuar pasando los
datos carácter e información acerca de la estructura lógica
del documento a la aplicación).
- opción de usuario
- Los programas conformadores pueden o
deben (dependiendo del tiempo verbal de la frase) comportarse
como se describe. Si lo hacen, deben proporcionar mecanismos
para deshabilitar el comportamiento descrito.
- restricción de validez
- Una regla que se aplica a todo
documento XML
válido.
Las violaciones de la restricción de validez son errores, y
los
procesadores
validadores de XML deben, por opción de usuario, informar
de ellas.
- restricción de buena-formación
- Una regla que se aplica a todo
documento XML
bien-formado.
Las violaciones de la restricción buena-formación son
errores
fatales.
- igualdad
- (de cadenas de
caracteres o nombres:) Dos cadenas de caracteres o nombres a
comparar deben ser idénticos. Los caracteres con múltiples
representaciones posibles en la norma ISO/IEC 10646 (p.e. los
caracteres con formas precompuestas y los "base+diacritic")
sólo son comparables si tienen la misma representación en
ambas cadenas. Por opción de usuario, los procesadores pueden
normalizar estos caracteres a alguna forma canónica (de
cadenas de caracteres y reglas en la gramática:) Una cadena
de caracteres es igual a una producción gramatical si
pertenece al lenguaje generado por esa producción. (de
contenido y modelos de contenido:) Un elemento es igual a su
declaración cuando conforma las reglas descritas en la
restricción de "Validez
de Elemento".
- por compatibilidad
- Una
característica de XML incluida únicamente para asegurar que
XML permanece compatible con SGML.
- por interoperatividad
- Una
recomendación no obligatoria incluida para incrementar las
funcionalidades de los documentos XML que pueden ser
procesados por la base instalada existente de procesador SGML
que añadan las adaptaciones WebSGML al ISO 8879.
Un objeto de
datos es un documento XML si esta
bien-formado,
tal y como se define en esta especificación. Un documento XML
bien-formado puede además ser
válido
si cumple una serie de restricciones.
Todo documento XML posee una estructura
lógica y una física. Físicamente, el documento está compuesto
de unidades llamadas
entidades.
Una entidad puede
hacer
referencia a otras entidades para que éstas sean incluidas en
el documento. Un documento comienza en una "raíz" o
entidad
documento. Lógicamente, el documento está compuesto de
declaraciones, elementos, comentarios, referencias a caracteres e
instrucciones de procesamiento, todos los cuales se indican en el
documento mediante marcas explícitas. Las estructuras lógica y
física deben anidarse de manera correcta, como se describe en el
punto "4.3.2 Entidades
Analizadas Bien-Formadas".
Un
objeto de texto es un documento XML bien-formado si:
-
Tomado
como un todo, cumple la regla denominada
document.
-
Respeta
todas las restricciones de buena-formación dadas en esta
especificación.
-
Cada
una de las
entidades
analizadas que se referencia directa o indirectamente en
el documento está
bien-formada.
Cumplir
la producción
document
implica que:
-
Contiene
uno o más
elementos.
-
Hay
exactamente un elemento, llamado raíz, o elemento documento,
del cual ninguna parte aparece en el
contenido
de ningún otro elemento. Para el resto de elementos, si la
etiqueta de comienzo está en el contenido de algún otro
elemento, la etiqueta de fin está en el contenido del mismo
elemento. Es decir, los elementos delimitados por etiquetas de
comienzo y final, de anidan adecuadamente mutuamente.
Como
consecuencia de esto, para cada elemento no raíz H en el
documento, existe otro elemento P tal que H está contenido en P,
pero no es el contenido de ningún otro elemento que esté en el
contenido de P. P es denominado padre de H, y H es hijo de P.
Una
entidad analizada contiene texto, una secuencia de
caracteres,
que pueden representar marcas o datos carácter. Un
carácter es una unidad atómica de texto como se especifica en la
norma ISO/IEC 10646
[ISO/IEC
10646]. Los caracteres legales son los tabuladores, retornos
de carro, finales de línea y los caracteres gráficos legales del
estándar Unicode y de la norma ISO/IEC 10646. La utilización de
"compatibilidad de caracteres", como se define en la
sección 6.8 de
[Unicode],
no está contemplada.
|
Rango
de Caracteres |
|
[2] |
Char |
::= |
#x9
| #xA | #xD | [#x20-#xD7FF]
| [#xE000-#xFFFD] | [#x10000-#x10FFFF] |
/* |
cualquier
carácter Unicode, excluyendo los bloques
subrogados FFFE y FFFF. */ |
|
Los
mecanismos para codificar los códigos de caracteres en patrones
de bits pueden variar de una entidad a otra. Todos los
procesadores XML deben aceptar las codificaciones UTF-8 y UTF-16
de la norma ISO/IEC 10646. El mecanismo para señalar cual de las
dos está en uso, o para definir otras codificaciones, se
discutirá más abajo en la sección "4.3.3 Codificación
de Caracteres en Entidades".
Esta
sección define algunos símbolos utilizados en la gramática.
El
símbolo
S (espacio en
blanco) está compuesto de uno o más caracteres espacio (#x20),
retornos de carro, finales de línea o tabuladores.
| Espacios en Blanco |
| [3] |
S |
::= |
(#x20
| #x9 | #xD | #xA)+ |
|
Los
caracteres se clasifican, por conveniencia, en letras, dígitos u
otros caracteres. Las letras se componen de caracteres de base
alfabética o silábica, seguidos de uno o más caracteres
combinatorios, o caracteres ideográficos. Las declaraciones
completas de cada clase de caracteres se da en "B. Clases
de Caracteres".
Un
Nombre es un "token" que comienza con una letra o uno o
más caracteres de puntuación, y que continua con letras,
dígitos, guiones, subrayados, comas y/o puntos. Los Nombres que
comienzan por la cadena "xml", o cualquiera que cumpla
la regla (('X'|'x') ('M'|'m') ('L'|'l')), quedan reservados para
estandarización en esta o futuras versiones de esta
especificación.
Nota:
El carácter dos puntos en los nombres XML está reservado para la
experimentación con espacios de nombres. Se prevé que se
estandarizará su significado en un futuro, en el que los
documentos que utilicen este carácter con propósitos
experimentales deberán ser actualizados. (No existe garantía de
que se adopte el mecanismo de espacios de nombres para XML). En la
práctica, esto significa que los autores no deberían utilizar
los dos puntos en XML, excepto como parte de espacios de nombres
experimentales. Sin embargo los procesadores XML deben aceptar
este carácter en los Nombres.
Un
"Nmtoken"
(name token) es cualquier combinación de caracteres de nombre.
Los
datos literales consisten en cualquier cadena entrecomillada que
no contenga el tipo de comillas utilizadas como delimitadores en
la propia cadena. Los literales se utilizan para especificar el
contenido de entidades internas ("EntityValue"),
los valores de los atributos ("AttValue")
y los identificadores externos ("SystemLiteral").
Hay que tener en cuenta que el símbolo "SystemLiteral"
puede ser analizado sin tomar en cuenta la presencia de marcas.
|
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 en
datos
carácter y marcas entremezcladas. Las
Marcas toman la forma de
etiquetas
de comienzo,
etiquetas
de fin,
etiquetas de
elementos vacíos,
referencias
a entidades,
referencias
a caracteres,
comentarios,
secciones CDATA
delimitadores,
declaraciones
de tipo de documento e
instrucciones
de procesamiento.
Todo
texto que no sea una marca constituye los denominados datos
carácter del documento.
El
carácter "ampersand" (&) y el paréntesis angular
de apertura (<) pueden aparecer de forma literal sólo cuando
se utilicen como delimitadores de marcas, o dentro de los
comentarios,
en
instrucciones de
procesamiento, o en
secciones
CDATA. También pueden utilizarse en los
valores
literales de entidad de una declaración de entidad interna;
ver "4.3.2 Entidades
Analizadas Bien-Formadas". Si son necesarios en cualquier
otro punto, deben ser "escapados"
mediante la utilización de
referencias
numéricas a caracteres, o mediante las cadenas "&"
y "<" respectivamente. El paréntesis angular de
cierre (>) puede ser representado utilizando la cadena
">", y debe,
por
compatibilidad, ser "escapado" utilizando
">" o la referencia a carácter cuando aparece
como contenido de la cadena "]]>", siempre y cuando
la cadena no marque el final de una
sección
CDATA.
En
el contenido de los elementos, los datos carácter son cualquier
cadena de caracteres que no contenga el delimitador de comienzo de
marca. En las secciones CDATA, los datos carácter son aquellos
que no se incluyan en el delimitador de fin de sección CDATA,
"]]>".
Para
permitir que los valores de los atributos puedan contener tanto
las comillas simples como las dobles, el carácter apóstrofe o
comilla simple (') puede ser representado como "'",
y el comilla doble (") como """.
|
Datos
Carácter |
|
[14] |
CharData |
::= |
[^<&]*
- ([^<&]* ']]>' [^<&]*) |
|
Los
Comentarios pueden aparecer en cualquier punto del documento,
fuera del resto de
marcas;
además, pueden aparecer en la declaración de tipo de documento,
en los lugares permitidos por la gramática. No son parte de los
datos
carácter del documento. Un procesador XML puede, pero no
debe, permitir a la aplicación obtener el texto de los
comentarios.
Por
compatibilidad, la cadena "--" (dos guiones) no
puede aparecer dentro de un comentario.
|
Comentarios |
|
[15] |
Comment |
::= |
'<!--'
((Char
- '-') | ('-' (Char
- '-')))* '-->' |
|
Un
ejemplo de comentario:
|
<!-- declaraciones de <head> y <body> --> |
Las
Instrucciones de Procesamiento (PIs) permiten a los documentos
contener instrucciones para las aplicaciones.
|
Instrucciones
de Procesamiento |
|
[16] |
PI |
::= |
'<?'
PITarget
(S (Char*
- (Char*
'?>'
Char*)))?
'?>' |
|
[17] |
PITarget |
::= |
Name
- (('X' | 'x') ('M' | 'm') ('L'
| 'l')) |
|
Las
PIs no son parte de los
datos
carácter del documento, pero deben ser pasadas a la
aplicación. Las PIs empiezan con un destino (PITarget)
utilizado para identificar a la aplicación a la que está
dirigida dicha instrucción. Los nombres de destino "XML",
"xml", y las combinaciones de mayúsculas y minúsculas
a partir de éstas, están reservados para estandarización en
esta o futuras versiones de esta especificación. El mecanismo de
Notación
XML puede ser utilizado para la declaración formal de destinos de
PIs.
Las
secciones CDATA pueden aparecer allá donde pueden aparecer los
datos carácter. Se utilizan para "escapar" bloques de
texto que contengan caracteres que de otra forma se reconocerían
como marcas. Las secciones CDATA comienzan por la cadena
"<![CDATA[" y terminan con la cadena
"]]>":
En
una sección CDATA sólo la cadena
CDEnd
se reconoce como marca, por lo tanto, el paréntesis angular de
apertura y el carácter "ampersand" pueden aparecer de
forma literal, es decir, no necesitan (y no pueden) ser
"escapados" mediante "<" ni "&".
No se pueden anidar las secciones CDATA.
Veamos
un ejemplo de sección CDATA, en el cual
"<saludo>" y "</saludo>" son
reconocidos como
datos
carácter, y no como
marcas:
|
<![CDATA[<saludo>Hola, mundo!</saludo>]]> |
Los
documentos XML pueden, y deberían, comenzar con una declaración
XML que especifica la versión de XML utilizada. Por ejemplo, el
siguiente es un documento XML completo,
bien-formado
pero no
válido:
<?xml version="1.0"?>
<saludo>Hola, mundo!</saludo>
|
y
también lo es:
<saludo>Hola, mundo!</saludo>
|
El
número de versión "1.0" debería utilizarse para
indicar la conformancia a esta versión de la especificación. Se
produce un error si un documento utiliza el valor "1.0"
y éste no conforma la especificación de esta versión. Es
intención del Grupo de Trabajo XML el proveer de nuevos números
versiones de esta especificación, pero no se asegura que habrán
futuras versiones de XML. Dado que no se han regulado futuras
versiones, esta construcción se ha permitido para posibilitar el
reconocimiento automáticamente de la versión, si fuese
necesario. Los procesadores deben indicar que existe un error si
reciben un documento etiquetado con una versión que no soportan.
La
función de las marcas en los documentos XML reside en describir
su almacenamiento y estructura lógica, así como asociar pares
atributo-valor con dicha estructura lógica. XML proporciona un
mecanismo, la
declaración
de tipo de documento, para definir restricciones sobre las
estructuras lógicas y para contemplar el uso de unidades de
almacenamiento predefinidas. Un documento
XML es válido si tiene asociada una declaración de tipo de
documento y si el documento cumple las restricciones que allí se
expresan.
La
declaración de tipo documento debe aparecer antes que el primer
elemento
en el documento.
La
declaración de tipo de documento XML, contiene o describe
declaraciones
de marcas que proporcionan una gramática para una clase de
documentos. Esta gramática se conoce como definición de tipo de
documento o DTD. La declaración de tipo de documento puede
referirse a un subconjunto externo (un tipo especial de
entidad
externa) que contiene declaraciones, o puede contener las
declaraciones de marcas directamente en un subconjunto interno, o
puede hacer ambos. Una DTD para un documento consiste en la unión
de ambos subconjuntos.
Una
declaración de marcación es una
declaración
de tipo de elemento, una
declaración
de lista de atributos, una
declaración
de entidad, o una
declaración
de notación. Estas declaraciones pueden estar contenidas en
su totalidad o en parte en las
entidades
parámetro, como se describe en las restricciones de
buena-formación y validez. Para más información al respecto,
ver la sección "4. Estructuras
Físicas".
|
Definición
de Tipo de Documento |
|
|
La
declaración de marcas puede estar constituida totalmente o en
parte de
texto de
reemplazo de
entidades
parámetro. Las reglas de producción que aparecerán en esta
especificación para los no terminales individuales (elementdecl,
AttlistDecl,
etc.) describen las declaraciones después de que todas las
entidades parámetro hayan sido
incluidas.
Restricción
de Validez: Tipo de Elemento Raíz
El
Nombre (Name) en la
declaración de tipo de documento debe ser igual al tipo de
elemento del
elemento
raíz.
Restricción
de Validez: Declaración Apropiada/Anidamiento de PEs
El
texto de reemplazo
de la entidad parámetro debe estar anidado apropiadamente dentro
de la declaración de marcas. Es decir, si el primer o el último
carácter en la declaración de una marca (markupdecl
arriba) está contenido en el texto de reemplazo para una
referencia
a entidad parámetro, ambos deben estar contenidos en el mismo
texto de reemplazo.
Restricción
de Buena-Formación: PEs en el Subconjunto Interno
En el subconjunto del DTD interno, las
referencias
a entidades parámetro sólo pueden aparecer donde puedan
aparecer las declaraciones de marcas, nunca dentro de las
declaraciones de marcas. (Esto no se aplica a las referencias que
aparecen en entidades parámetro externas o en el subconjunto
externo.)
Como
en el subconjunto interno, el subconjunto externo y cualquier
entidad parámetro externa referenciada en el DTD debe consistir
de una serie de declaraciones completas de marcas de los tipos
permitidos por el símbolo no-terminal
markupdecl,
intercaladas con espacios en blanco o
referencias
a entidades parámetro. Sin embargo, porciones de los
contenidos del subconjunto externo o de las entidades parámetro
externas pueden ser ignoradas condicionalmente mediante la
utilización de la construcción
sección
condicional; esto no está permitido en el subconjunto
interno.
El
subconjunto externo y las entidades parámetro externas también
difieren del subconjunto interno en que en ellos, las
referencias
a entidades parámetro son permitidas dentro de las
declaraciones de marcas, no sólo entre de ellas.
Un
ejemplo de un documento XML con una declaración de tipo de
documento:
<?xml version="1.0"?>
<!DOCTYPE saludo SYSTEM "hola.dtd">
<saludo>Hola, mundo!</saludo>
|
El
identificador de sistema
"hola.dtd" proporciona el URI de una DTD para el
documento.
Las
declaraciones pueden también darse localmente, como es este
ejemplo:
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE saludo [
<!ELEMENT saludo (#PCDATA)>
]>
<saludo>Hola, mundo!</saludo>
|
En
ambos se utilizan tanto en el subconjunto interno, como en el
externo. El interno se considera que aparezca antes que el
externo. Esto indica que las declaraciones de entidades y de
listas de atributos en el subconjunto interno toman precedencia
sobre las de externo.
Las
declaraciones de marcas pueden afectar al contenido de un
documento, como cuando se pasan de un
procesador
XML a una aplicación; un ejemplo de esto son los valores por
defecto de los atributos y las declaraciones de entidades. La
declaración de documento standalone, que puede aparecer como
componente de la declaración XML, señala si existen o no dichas
declaraciones que aparecen externamente a la
entidad
documento.
|
Declaración
de Documento Standalone |
|
|
En
la declaración de documento standalone, el valor "yes"
indica que no existen declaraciones de marcas externas a la
entidad
documento (ni en el subconjunto externo del DTD, ni en una
entidad parámetro externa referenciada desde el subconjunto
interno) que afecte a la información pasada desde el procesador
XML a la aplicación. El valor "no" indica que existe o
que pueden haber dichas declaraciones externas de marcas. La
declaración de documento standalone sólo denota la presencia de
declaraciones externas; la presencia, en un documento, de
referencias a entidades externas, cuando esas entidades son
declaradas internamente, no cambia el estado standalone del
documento.
Si
no existen declaraciones externas de marcas, la declaración de
documento standalone no tiene sentido. Si, por el contrario,
existiesen, pero no hay ninguna declaración de documento
standalone, se asume el valor "no".
Cualquier
documento XML para el cual standalone="no" puede
convertirse algorítmicamente en un documento standalone, el cual
puede ser necesario para algunas aplicaciones de envío en un
entorno de redes.
Restricción
de Validez: Declaración de Documento Standalone
La declaración de documento standalone debe tener el valor
"no" si cualquier declaración externa de marcas
contiene:
-
atributos
con valores por
defecto,
si los elementos a los que se aplican esos atributos aparecen
en el documento sin especificaciones de valores para esos
atributos, o
-
entidades
(que no sean amp, lt, gt, apos, quot), si las
referencias
a esas entidades aparecen en el documento, o
-
atributos
con valores sujetos a
normalización,
donde el atributo aparece en el documento con un valor que
cambiará como resultado de la normalización, o
-
tipos
de elementos con
contenido
de elemento, si aparecen espacios en blanco directamente
dentro de cualquier instancia de esos tipos.
Un
ejemplo de declaración XML con una declaración de documento
standalone:
|
<?xml version="1.0" standalone='yes'?> |
En
la edición de documentos XML, suele ser conveniente utilizar
"espacios en blanco" (espacios, tabuladores y líneas en
blanco, denotadas por el no terminal
S
en esta especificación) para mantener la legibilidad de las
marcas. Generalmente estos caracteres no deben incluirse en una
posible versión distribuible del documento a través de una red.
Por otro lado, existen ocasiones en las que es deseable la
existencia de esos "espacios", por ejemplo en poesía y
en la representación de código fuente.
Un
procesador XML
debe pasar siempre todos los caracteres de un documento, que no
sean marcas, a la aplicación. Un
procesador
XML validador
debe informar también a la aplicación acerca
de los caracteres que constituyen los "espacios en
blanco" contenidos en el
contenido
del elemento.
Un
atributo especial
denominado xml:space puede ser adjuntado a un elemento para
señalar la necesidad de mantener los caracteres
"espacio" en dicho elemento. Los "espacios"
deben ser preservados por las aplicaciones. En los documentos
válidos, este atributo, como cualquier otro, debe ser
declarado
si se utiliza. Cuando se declara, debe darse como un
tipo
enumerado cuyo único valor posible es "default" y
"preserve". Por ejemplo:
|
<!ATTLIST poema xml:space (default|preserve) 'preserve'> |
El
valor "default" indica que el procesamiento por defecto
por parte de las aplicaciones de los "espacios en
blanco" es aceptable para este elemento. El valor
"preserve" indica que las aplicaciones deben preservar
todos los "espacios en blanco". Esta declaración se
considera aplicable a todos los elementos dentro del contenido del
elemento donde esta especificada, salvo que se anule con otra
instancia del atributo xml:space.
Se
considera que el
elemento
raíz de los documento, por defecto, no requiere el manejo
especial de "espacios" de la aplicación, si no tiene
declarado este atributo.
Las
entidades analizadas
XML son frecuentemente almacenadas en archivos de ordenador, y por
conveniencia de edición, están organizados en líneas. Estas
líneas están típicamente separadas por una combinaciones de
caracteres formada por "retorno de carro" (#xD) y
"fin de línea" (#xA).
Para
simplificar las tareas de las
aplicaciones,
bien sea una entidad analizada externa o una entidad valor literal
de una entidad analizada interna, ambas contienen la secuencia
literal de dos caracteres "#xD#xA" o un único literal #xD.
Un
procesador XML
debe pasar únicamente a la aplicación el carácter #xA. (Este
comportamiento puede ser producido mediante la normalización de
todos los "fines de línea" a caracteres #xA antes de
ser analizados).
En
el procesado de documentos, suele ser útil la identificación
entre el lenguaje natural o el lenguaje formal, en el que está
escrito el contenido. Un
atributo
especial denominado xml:lang puede ser insertado en los documentos
para especificar el lenguaje utilizado en los contenidos y los
valores de atributos de cualquier elemento en un documento XML. En
los documentos válidos, este atributo, como cualquier otro, debe
ser
declarado si se
utiliza. Los valores de este atributo son identificadores de
lenguajes como los definidos en el documento
[IETF
RFC 1766], "Etiquetas para la Identificación de
Lenguajes":
|
Identificación
de Lenguaje |
|
[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])+ |
|
La
producción
Langcode
puede ser cualquiera de las siguientes:
-
un
código de dos letras como se define en la norma
[ISO
639], "Códigos para la representación de nombres de
lenguajes"
-
un
identificador de lenguaje registrado con la Internet Assigned
Numbers Authority
[IANA];
éstos comienzan con el prefijo "i-" (o "I-")
-
un
identificador de lenguaje asignado por el usuario, o convenido
entre las partes en uso privado; éstos deben comenzar con el
prefijo "x-" o "X-", de manera que se
asegure que no entran en conflicto con nombres que puedan ser
estandarizados o registrados por la IANA
Puede
haber cualquier número de segmentos
Subcode.
Si el primer segmento de subcódigo existe y ese subcódigo
consiste en dos letras, éste debe pertenecer al código de un
país de la norma
[ISO
3166], "Códigos para la representación de nombres de
países". Si el primer subcódigo contiene más de dos
letras, éste debe ser un subcódigo para el lenguaje en
cuestión, registrado por la IANA, a no ser que
Langcode
comience por el prefijo "x-" o "X-".
Se
suele acordar dar el código del lenguaje en minúsculas, y el
código del país (si tuviese) en mayúsculas. Hay que resaltar
que estos valores, a diferencia del resto de nombres en XML, son
representables indistintamente en minúsculas o en mayúsculas.
Por
ejemplo:
<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> |
El
atributo xml:lang declarado se considera que debe aplicarse a
todos los atributos y al contenido de los elementos donde esta
especificado, a no ser que sea anulado por otra instancia de
xml:lang en otro elemento de ese contenido.
Una
simple declaración para xml:lang puede tomar la forma:
|
xml:lang NMTOKEN #IMPLIED |
pero
también pueden darse los valores por defecto específicos. En una
colección de poemas franceses para estudiantes ingleses, con
notas en inglés, el atributo xml:lang puede ser declarado de la
siguiente manera:
<!ATTLIST poema xml:lang NMTOKEN 'fr'>
<!ATTLIST anotación xml:lang NMTOKEN 'en'> |
Cada
documento XML
contiene uno o más elementos, cuyos límites están delimitados
por
etiquetas de comienzo
y
etiquetas de fin, o
en los elementos
vacíos,
por una
etiqueta de
elemento vacío. Cada elemento tiene un tipo, identificado por
un nombre, a veces denominado "identificador genérico"
(GI: Generic Identifier), y puede tener un conjunto de
especificaciones de atributos. Cada una de éstas tiene un
nombre
y un
valor.
Esta
especificación no restringe la semántica, la utilización, o
(más allá de la sintaxis) los nombres de los tipos de elementos
y de los atributos, excepto los nombres que comiencen por
(('X'|'x')('M'|'m')('L'|'l')) que están reservados para
estandarización en esta o en futuras versiones de esta
especificación.
Restricción
de Buena-Formación: Igual de Tipo de Elemento
El
Nombre en la
etiqueta de fin de un elemento debe ser igual al de la etiqueta de
comienzo.
Restricción
de Validez: Elemento Válido
Un elemento es válido si existe una declaración que cumpla con
la regla
elementdecl
donde el
Nombre sea
igual al tipo de elemento, y uno se mantenga uno de los
siguientes:
-
La
declaración cumple la regla EMPTY y el elemento no tiene
contenido.
-
La
declaración cumple la regla 'children'
y la secuencia 'elementos
child' pertenece al lenguaje generado por la expresión
regular en el modelo de contenido, con espacios en blanco
opcionales (caracteres que cumplan la regla
S)
entre todo par de elementos 'child'.
-
La
declaración cumple la regla 'Mixed'
y el contenido de la misma consiste en
datos
carácter y 'elementos
child' cuyos tipos sean iguales a los nombres del modelo
de contenido.
-
La
declaración cumple la regla ANY, y los tipos de cualquier 'elemento
child' han sido declarados.
El
comienzo de todo elemento XML no vacío está marcado por una
etiqueta de comienzo.
El
Nombre en las
etiquetas de comienzo y de fin proporciona el tipo del elemento. Los
pares
Name-AttValue
son referidos como las especificaciones de atributos del elemento,
con el
Name
en cada par referido como el nombre de atributo y el
contenido del
AttValue
(el texto entre los delimitadores ' o ") como el valor del
atributo.
Restricción
de Buena-Formación: Especificación de Atributo Único
ningún nombre de atributo puede aparecer más de una vez en la
misma etiqueta de comienzo o de "elemento-vacío".
Restricción
de Validez: Tipo de Valor de los Atributos
El atributo debe haber sido declarado, el valor debe ser del tipo
declarado para él. (Para tipos de atributos, ver "3.3 Declaraciones
de Listas de Atributos").
Restricción
de Buena-Formación: No Referencia a Entidades Externas
Los valores de los atributos no pueden contener entidades
referencia directas o indirectas a entidades externas.
Restricción
de Validez: No < en Valores de Atributos
El
texto de reemplazo
de cualquier entidad referenciada directa o indirectamente en un
valor de atributo (cualquiera salvo "<") no debe
contener el carácter <.
Un
ejemplo de etiqueta de comienzo podría ser:
|
<defterm id="dt-perro" term="perro"> |
El
final de todo elemento que comience con una etiqueta de comienzo
debe ser marcado con una etiqueta de fin que contenga un nombre
que responda al tipo de elemento dado en la etiqueta de comienzo:
|
Etiqueta
de Fin |
|
[42] |
ETag |
::= |
'</'
Name
S?
'>' |
|
Un
ejemplo de etiqueta de fin:
El
texto entre las
etiquetas de comienzo y de fin se denomina contenido:
|
Contenido
de los Elementos |
|
|
Si
un elemento está vacío, debe ser representado por una etiqueta
de comienzo seguida de una etiqueta de fin, o por una etiqueta de
"elemento-vacío". Una etiqueta
de "elemento-vacío" tiene la siguiente forma:
|
Etiquetas
para Elementos Vacíos |
|
|
Las
etiquetas de "elemento-vacío" pueden ser utilizadas por
cualquier elemento que no tenga contenido, sea o no declarado
mediante la utilización de la palabra clave EMPTY.
Por
interoperatividad, la etiqueta de "elemento-vacío"
debe ser utilizada, y sólo puede ser utilizada, en elementos que
estén
declarados
como EMPTY.
Ejemplos
de "elementos-vacíos":
<IMG align="left"
src="http://www.w3.org/Icons/WWW/w3c_home" />
<br></br>
<br/> |
La
estructura
elemento
de un
documento XML
puede, a efectos de
validación,
estar restringida mediante la utilización de declaraciones de
tipos de elementos y de listas de atributos. Una declaración de
tipo de elemento restringe el
contenido
del propio elemento.
Las
declaraciones de tipo de elemento suelen restringir el tipo de
elementos que pueden aparecer como 'children'
del citado elemento. Un procesador XML puede indicar una
advertencia cuando una declaración menciona un tipo de elemento
para el que no se ha dado una declaración, como opción del
usuario, dado que esto no supone ser un error.
Una
declaración de tipo de elemento es de la forma:
|
Declaración
de Tipo de Elemento |
|
|
donde
la producción
Name
proporciona el tipo de elemento que se está declarando.
Restricción
de Validez: Declaración Única de Tipo de Elemento
Ningún tipo de elemento debe ser declarado más de una vez.
Ejemplos
de declaraciones de tipo de elemento:
<!ELEMENT br EMPTY>
<!ELEMENT p (#PCDATA|emph)* >
<!ELEMENT %name.para; %content.para; >
<!ELEMENT contenedor ANY> |
Un
tipo de elemento tiene
contenido del elemento cuando los elementos de ese tipo deben
contener sólo elementos
hijos
(no datos carácter), opcionalmente separados por "espacios
en blanco" (caracteres que cumplan la regla
S).
En este caso, la restricción incluye un modelo de contenido, una
gramática simple que gobierna los tipos de 'elementos hijo'
permitidos y el orden en que pueden aparecer. La gramática está
constituida por partículas de contenido (cps),
que consisten en nombres, 'listas de selección' de partículas de
contenido o 'listas secuencia' de partículas de contenido:
|
Modelos
de Contenido de Elemento |
|
|
donde
cada 'Name' es el tipo
de un elemento que puede aparecer como un 'child'.
Cualquier partícula de contenido en una lista de selección puede
aparecer en el
contenido
del elemento donde la lista de selección aparece en la
gramática. Las partículas de contenido que aparecen en las
listas de secuencias deben aparecer cada una en el
contenido
del elemento en el orden dado en la lista. El carácter
opcional que sigue a un nombre o una lista gobierna si el elemento
o las partículas de contenido en la lista pueden aparecer una o
más veces (+), cero o más (*), o cero o una vez (?). La ausencia
de dicho operador significa que el elemento o partícula de
contenido debe aparecer exactamente una vez. Esta sintaxis y su
significado son idénticos a los utilizados en las reglas de
producción de esta especificación.
El
contenido de una elemento es igual al modelo de contenido si y
sólo si es posible trazar una ruta a través del modelo de
contenido, obedeciendo la secuencia, opción y operadores de
repetición e igualando cada elemento en el contenido contra un
tipo de elemento en el modelo de contenido.
Por
compatibilidad, se produce un error si un elemento del
documento puede ser igual a más de una ocurrencia de un tipo de
elemento en el modelo de contenido. Para más información, ver
"E. Modelos
de Contenido Deterministas".
Restricción
de Validez: Grupo apropiado/Anidamiento de PEs
Las entidades parámetro
texto
de reemplazo deben ser anidadas apropiadamente con grupos de
paréntesis. Es decir, si cualquiera de los paréntesis de
apertura o de cierre de una construcción
choice,
seq o
Mixed
está contenida en el texto de reemplazo para una
entidad
parámetro, ambas deben estar contenidas en el mismo texto de
reemplazo.
Por
interoperatividad, si una entidad parámetro aparece en una
construcción
choice,
seq o
Mixed,
su texto de reemplazo no tendría que estar vacío, y ni el
primero ni el último carácter 'no-blanco' del texto de reemplazo
debe ser un 'conector'. (| o ,).
Ejemplos
de modelos de contenido de elemento:
<!ELEMENT especif (frente, cuerpo, epilogo?)>
<!ELEMENT div1 (cabecera, (p | lista | nota)*, div2*)>
<!ELEMENT cuerpo-diccionario (%div.mix; | %dict.mix;)*> |
Un
tipo de elemento tiene
"contenido mezclado" cuando los elementos de ese tipo
pueden contener datos carácter, opcionalmente entremezclados con
elementos
child.
En este caso, los tipos de los elementos 'child' pueden ser
restringidos, pero no su orden o su número de apariciones:
|
Declaración
de "Contenido Mezclado" |
|
|
donde
las construcciones
Name
dan los tipos de los elementos que pueden aparecer como hijos.
Restricción
de Validez: No Duplicación de Tipos
El mismo nombre no debe aparecer más de una vez en una sola
declaración de "contenido mezclado".
Ejemplos
de declaraciones de contenido mezclado:
<!ELEMENT p (#PCDATA|a|ul|b|i|em)*>
<!ELEMENT p (#PCDATA | %font; | %phrase; | %special; | %form;)* >
<!ELEMENT b (#PCDATA)> |
Los
atributos se utilizan
para asociar pares nombre-valor con
elementos.
Las especificaciones de atributos pueden aparecer sólo dentro de
las
etiquetas de comienzo
y en las
etiquetas de
elemento vacío. Las reglas de producción utilizadas para
reconocer su aparición en "3.1 Etiquetas
de Comienzo, Etiquetas de Fin y Etiquetas de Elementos-Vacíos".
Las declaraciones de Listas de Atributos pueden utilizarse para:
-
Definir
el conjunto de atributos pertenecientes a un tipo de elemento
dado.
-
Establecer
restricciones de tipo para dichos atributos.
-
Proporcionar
valores por defecto
para los atributos.
Las
declaraciones de Listas de Atributos especifican el nombre, tipo
de datos y valores por defecto (si tuvieran) para cada atributo
asociado con un tipo de elemento dado:
|
Declaraciones
de Listas de Atributos |
|
|
La
expresión
Name en la
regla
AttlistDecl
es tipo del elemento. Como opción de usuario, los procesadores
XML pueden indicar si los atributos están declarados para un tipo
de elemento que no está declarado, hecho que no constituye un
error. La expresión
Name
en la regla
AttDef
es el nombre del atributo.
Cuando
se proporciona más de una
AttlistDecl
para un tipo de elemento dado, los contenidos de todos esas
declaraciones se entremezclan. Cuando se proporciona más de una
definición para el mismo atributo de un tipo de elemento dado, se
mantiene la primera declaración y se ignora el resto.
Por
interoperatividad, los creadores de DTDs deben proporcionar,
al menos, una declaración de lista de atributos para un tipo de
elemento dado, una definición de atributo para un nombre de
atributo dado, y por lo menos una definición de atributo en cada
declaración de lista de atributos Por interoperatividad, los
procesadores XML pueden indicar una alerta cuando se proporciona
más de una declaración de lista de atributos para un tipo de
elemento dado, o más de una definición de atributo para una
atributo dado. Esta es una opción de usuario y no supone ningún
tipo de error.
Los
tipos de atributos de XML son de tres tipos: el tipo cadena, el
conjunto de los tipos 'tokenizados' y los tipos enumerados. El
tipo cadena puede tomar cualquier cadena literal como valor. Los
tipos 'tokenizados' poseen restricciones léxicas y semánticas
variantes, como se describe a continuación:
Restricción
de Validez: ID
Los valores de tipo ID deben ser iguales a la regla de producción
Name. Un nombre no
puede aparecer más de una vez de un documento XML como valor de
este tipo. P.e.: los valores de ID sólo deben identificar a los
elementos que los producen.
Restricción
de Validez: Un ID por Tipo de Elemento
Ningún tipo de elemento puede tener más de un atributo ID
especificado.
Restricción
de Validez: Atributo por Defecto ID
Un atributo ID debe tener declarado por defecto el valor #IMPLIED
o #REQUIRED.
Restricción
de Validez: IDREF
Los valores del tipo IDREF deben ser iguales a la regla de
producción
Name, y
los valores del tipo IDREFS deben ser iguales a
Names.
Cada
Name debe ser
igual al valor de un atributo ID de alguno de los elementos del
documento XML. P.e. los valores de IDREF deben ser iguales a los
valores de algún atributo ID.
Restricción
de Validez: Nombre de Entidad
Los valores del tipo ENTITY deben ser iguales a la regla de
producción
Name, los
valores del tipo ENTITIES deben ser iguales a
Names.
Cada
Name debe ser
igual al nombre de una
entidad
no analizada declarada en la
DTD.
Restricción
de Validez: Nombre de Token
Los valores del tipo NMTOKEN deben ser iguales a la regla de
producción
Nmtoken,
los valores del tipo NMTOKENS deben ser iguales a
Nmtokens.
Los
atributos enumerados pueden tomar una de las listas de valores
proporcionadas en la declaración. Existen dos tipos de tipos
enumerados:
|
Tipos
de Atributos Enumerados |
|
|
Un
atributo NOTATION identifica una
notación,
declarada en la DTD con su sistema asociado y/o identificadores
públicos, para ser utilizados en la interpretación del elemento
al cual está unido el atributo.
Restricción
de Validez: Atributos de Notación
Los valores de este tipo deben ser iguales a los del nombre de
notación
incluidos en la declaración. Todos los nombres de notación de la
declaración deben ser declarados.
Restricción
de Validez: Enumeración
Los valores de este tipo deben ser iguales a los de los tokens
Nmtoken
de la declaración.
Por
interoperatividad,
no puede aparecer el mismo
Nmtoken
más de una vez en los tipos de atributos enumerados de un único
tipo de elemento.
Una
declaración de
atributos proporciona información sobre si la presencia de
los atributos es requerida, o sino, como debe reaccionar un
procesador XML si un atributo declarado está ausente en un
documento.
En
una declaración de atributo, #REQUIRED significa que ese atributo
debe ser dado siempre, #IMPLIED que no se da un valor por defecto.
Si la declaración no es ni #REQUIRED ni
#IMPLIED, entonces el valor
AttValue
contiene el valor por defecto declarado. La palabra clave #FIXED
indica que el atributo debe siempre tener el valor por defecto. Si
se declara el valor por defecto, cuando un procesador XML
encuentra un atributo omitido, debe comportarse como si el
atributo estuviese presente, con el valor por defecto declarado.
Restricción
de Validez: Atributo Requerido
Si la declaración por defecto es la palabra clave #REQUIRED, el
atributo debe ser especificado para todos los elementos del tipo
de la declaración de la lista de atributos.
Restricción
de Validez: Atributo por Defecto Legal
El valor por defecto declarado debe cumplir las restricciones
léxicas del tipo de atributo declarado.
Restricción
de Validez: Atributo por Defecto Fijado
Si un atributo tiene un valor por defecto declarado con la palabra
clave #FIXED, las instancias de ese atributo deben ser iguales al
valor por defecto.
Ejemplos
de declaraciones de listas de atributos:
<!ATTLIST defterm
id ID #REQUIRED
nombre CDATA #IMPLIED>
<!ATTLIST lista
tipo (ordenada|glosario) "ordenada">
<!ATTLIST formulario
metodo CDATA #FIXED "POST"> |
CURSO DE XLM PARTE 2 |