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
ident |