CURSO DE XLM PARTE 1

Agréganos a tus Favoritos

CURSO DE XLM PARTE 2


Extensible Markup Language (XML) 1.0
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


1. Introducción

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.

1.1 Origen y Objetivos

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:

  1. XML debe ser directamente utilizable sobre Internet.
  2. XML debe soportar una amplia variedad de aplicaciones.
  3. XML debe ser compatible con SGML.
  4. Debe ser fácil la escritura de programas que procesen documentos XML.
  5. El número de características opcionales en XML debe ser absolutamente mínima, idealmente cero.
  6. Los documentos XML deben ser legibles por humanos y razonablemente claros.
  7. El diseño de XML debe ser preparado rápidamente.
  8. El diseño de XML debe ser formal y conciso.
  9. Los documentos XML deben ser fácilmente creables.
  10. 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.

1.2 Terminología

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.

2. Documentos

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".

2.1 Documentos XML Bien-Formados

Un objeto de texto es un documento XML bien-formado si:

  1. Tomado como un todo, cumple la regla denominada document.
  2. Respeta todas las restricciones de buena-formación dadas en esta especificación.
  3. Cada una de las entidades analizadas que se referencia directa o indirectamente en el documento está bien-formada.
Documento
[1]  document ::= prolog element Misc*

Cumplir la producción document implica que:

  1. Contiene uno o más elementos.
  2. 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.

2.2 Caracteres

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".

2.3 Construcciones Sintácticas Comunes

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.

Nombres y "Tokens"
[4]  NameChar ::= LetterDigit | '.' | '-' | '_' | ':' | CombiningCharExtender
[5]  Name ::= (Letter | '_' | ':') (NameChar)*
[6]  Names ::= Name (S Name)*
[7]  Nmtoken ::= (NameChar)+
[8]  Nmtokens ::= Nmtoken (S Nmtoken)*

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 ::= '"' ([^%&"] | PEReferenceReference)* '"'
      |"'" ([^%&'] | PEReferenceReference)* "'"
[10]  AttValue ::= '"' ([^<&"] | Reference)* '"'
      | "'" ([^<&'] | Reference)* "'"
[11]  SystemLiteral ::= ('"' [^"]* '"') | ("'" [^']* "'")
[12]  PubidLiteral ::= '"' PubidChar* '"' | "'" (PubidChar - "'")* "'"
[13]  PubidChar ::= #x20 | #xD | #xA | [a-zA-Z0-9] | [-'()+,./:=?;!*#@$_%]

 

2.4 Datos Carácter y Marcas

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 "&amp;" y "&lt;" respectivamente. El paréntesis angular de cierre (>) puede ser representado utilizando la cadena "&gt;", y debe, por compatibilidad, ser "escapado" utilizando "&gt;" 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 "&apos;", y el comilla doble (") como "&quot;".

Datos Carácter
[14]  CharData ::= [^<&]* - ([^<&]* ']]>' [^<&]*)

2.5 Comentarios

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

   

2.6 Instrucciones de Procesamiento

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.

2.7 Secciones CDATA

Las secciones CDATA pueden aparecer allá donde pueden aparecer los datos carácter. Se utilizan para "escapar" bloques de texto que contengan caracteres que de otra forma se reconocerían como marcas. Las secciones CDATA comienzan por la cadena "<![CDATA[" y terminan con la cadena "]]>":

Secciones CDATA
[18]  CDSect ::= CDStart CData CDEnd
[19]  CDStart ::= '<![CDATA['
[20]  CData ::= (Char* - (Char* ']]>' Char*))
[21]  CDEnd ::= ']]>'

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 "&lt;" ni "&amp;". 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>]]>

 

2.8 Prolog y Declaración de Tipo de Documento

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.

Prolog
[22]  prolog ::= XMLDecl? Misc* (doctypedecl Misc*)?
[23]  XMLDecl ::= '<?xml' VersionInfo EncodingDecl? SDDecl? S? '?>'
[24]  VersionInfo ::= S 'version' Eq (' VersionNum ' | " VersionNum ")
[25]  Eq ::= S? '=' S?
[26]  VersionNum ::= ([a-zA-Z0-9_.:] | '-')+
[27]  Misc ::= CommentPI S

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
[28]  doctypedecl ::= '<!DOCTYPE' S Name (S ExternalID)? S? ('[' (markupdeclPEReferenceS)* ']' S?)? '>' [ RV: Tipo de Elemento Raíz ]
[29]  markupdecl ::= elementdeclAttlistDeclEntityDeclNotationDeclPIComment [ RV: Declaración Apropiada/Anidamiento de PEs ]
        [ RBF: PEs en Subconj Interno ]

La declaración de marcas puede estar constituida totalmente o en parte de texto de reemplazo de entidades parámetro. Las reglas de producción que aparecerán en esta especificación para los no terminales individuales (elementdecl, AttlistDecl, etc.) describen las declaraciones después de que todas las entidades parámetro hayan sido incluidas.

Restricción de Validez: Tipo de Elemento Raíz
El
Nombre (Name) en la declaración de tipo de documento debe ser igual al tipo de elemento del elemento raíz.

Restricción de Validez: Declaración Apropiada/Anidamiento de PEs
El
texto de reemplazo de la entidad parámetro debe estar anidado apropiadamente dentro de la declaración de marcas. Es decir, si el primer o el último carácter en la declaración de una marca (markupdecl arriba) está contenido en el texto de reemplazo para una referencia a entidad parámetro, ambos deben estar contenidos en el mismo texto de reemplazo.

Restricción de Buena-Formación: PEs en el Subconjunto Interno
En el subconjunto del DTD interno, las
referencias a entidades parámetro sólo pueden aparecer donde puedan aparecer las declaraciones de marcas, nunca dentro de las declaraciones de marcas. (Esto no se aplica a las referencias que aparecen en entidades parámetro externas o en el subconjunto externo.)

Como en el subconjunto interno, el subconjunto externo y cualquier entidad parámetro externa referenciada en el DTD debe consistir de una serie de declaraciones completas de marcas de los tipos permitidos por el símbolo no-terminal markupdecl, intercaladas con espacios en blanco o referencias a entidades parámetro. Sin embargo, porciones de los contenidos del subconjunto externo o de las entidades parámetro externas pueden ser ignoradas condicionalmente mediante la utilización de la construcción sección condicional; esto no está permitido en el subconjunto interno.

Subconjunto Externo
[30]  extSubset ::= TextDecl? extSubsetDecl
[31]  extSubsetDecl ::= ( markupdeclconditionalSectPEReferenceS )*

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