Especificación XML 1.0

eXtensible Markup Language

 

Documentos XML

Un objeto de datos se considera un documento XML si está 'bien formado' de acuerdo con la especificación XML. Si además cumple otra serie de condiciones (p.e. las impuestas por su DTD), será considerado un documento XML válido.

Los documentos XML tienen una estructura lógica y una estructura física.

Físicamente están compuestos por entidades. Cada entidad puede hacer referencia a otras entidades, que serán incluidas en el documento. Estas entidades pueden ser analizables (p.e. trozos XML) o no analizables (p.e. imágenes o ficheros de música).

Un documento comienza en una entidad raíz o entidad de documento (document entity).

Desde el punto de vista lógico, los documentos están compuestos por declaraciones, elementos, comentarios, referencias de caracteres e instrucciones de procesamiento. Todas estas estructuras lógicas son indicadas mediante las correspondientes marcas.

Un documento se considera ‘bien formado’ si:

  • Tomado como un todo, el documento XML cumple la especificación de documento [1] , es decir, tiene un prólogo*, un elemento principal (dentro del cual pueden ir otros elementos) y puede terminar con comentarios, instrucciones de procesamiento o espacios en blanco.
  • Cumple todos los requerimientos dados por la especificación XML
  • Todas las entidades a las que hace referencia, directa o indirectamente, están ‘bien formadas’

[1] document ::= prolog element Misc*

* Aunque la especificación de documento, [1], impone la existencia de un prólogo, la especificación de prólogo, [22], indica que éste puede estar vacío.

Cumplir la especificación de documento [1] implica que:

  • El documento contiene uno o más elementos (contiene un elemento principal -raíz/root- que contiene a los demás elementos anidados correctamente)
  • Hay un (y sólo un) elemento raíz (elemento documento). Ninguna parte del mismo aparece en el contenido de cualquier otro elemento. Los demás elementos deben ser anidados de forma adecuada. Todos los elementos deben comenzar con una marca de inicio y terminar con una marca de finalización (excepto los elementos vacíos) y no puede haber elementos solapados.

Ejemplo de un documento mal formado (las marcas no se anidan correctamente):

<saludo> Estimado
      <destinatario>Sr. Gómez
</saludo>
      </destinatario>

El mismo documento, bien formado.

<saludo> Estimado
      <destinatario>Sr. Gómez  </destinatario>
</saludo>


Un documento ‘bien formado’ no es equivalente a un documento válido. El documento ‘bien formado’ es el que tiene todos los elementos bien anidados y estos elementos cumplen con las especificaciones XML. Un documento válido es aquel que además ha definido (declarado) correctamente todos sus elementos y cumple con las especificaciones asignadas a cada uno en el DTD.

 

Caracteres

Cada entidad está formada por texto (secuencias de caracteres) que puede representar tanto datos como marcas XML.

Cada carácter es la unidad mínima (atómica) de texto. Son caracteres válidos:  
TAB (tabulación), CR (retorno de carro), LF (nueva línea), así como los caracteres de Unicode e ISO/IEC 10646.

[2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]

Es decir, cualquier carácter Unicode excepto #xFFFE y #xFFFF

 

Constructores sintácticos

En este apartado se hace referencia a una serie de constructores con significado especial y que son utilizados ampliamente en la especificación.

S (espacio en blanco) : uno o más espacios (#x20), CR, LF o TAB’s

[3] S ::= (#x20 | #x9 | #xD | #xA)+

Name (nombre): es un elemento (token) que comienza por una letra (o algún carácter de puntuación permitido) y continúa con letras, dígitos, guiones, caracteres de subrayado, dos puntos*, or full stops. Los nombre que comienzan con ‘xml’ (en mayúsculas o minúsculas) están reservados.

Aunque el carácter ':' (dos puntos) puede ser utilizado como parte de un nombre, no es aconsejable utilizarlo ya que es posible que versiones futuras de la especificación le den un significado especial.

[4] NameChar ::= Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar | Extender
[5] Name ::= (Letter | '_' | ':') (NameChar)*
[6] Names ::= Name (S Name)*
[7] Nmtoken ::= (NameChar)+
[8] Nmtokens ::= Nmtoken (S Nmtoken)*

Datos literales: Cualquier cadena acotada que no contenga la marca de acotación usada como delimitador de la propia cadena. Los datos literales pueden ser entidades internas (EntityValue), valores de atributos (AttValue) e identificadores externos (SystemLiteral).

[9] EntityValue ::= '"' ([^%&"] | PEReference | Reference)* '"'
                   | "'" ([^%&'] | PEReference | Reference)* "'"

[10] AttValue ::= '"' ([^<&"] | Reference)* '"' | "'" ([^<&'] | Reference)* "'"
[11] SystemLiteral ::= ('"' [^"]* '"') | ("'" [^']* "'")

Lo que quiere decir que el contenido de un SystemLiteral (desde las comillas de comienzo hasta las del final) no debe ser analizado en busca de marcas de elemento.

[12] PubidLiteral ::= '"' PubidChar* '"' | "'" (PubidChar - "'")* "'"
[13] PubidChar ::= #x20 | #xD | #xA | [a-zA-Z0-9] | [-'()+,./:=?;!*#@$_%]

Ejemplos de datos literales:

<!ENTITY firma "Felipe Fdez. Perera">
<!ENTITY firma_ext SYSTEM 'http://www.epsilon-eridani.com/firma.xml'>
...
<saludo tipo='oficial'></saludo>

Para incluir un carácter " (comilla doble) o ' (comilla simple) dentro de un literal:

<saludo tipo="no 'oficial'"></saludo>
<saludo tipo='otro "tipo" de saludo'></saludo>

 

Caracteres de datos y marcas

El texto está compuesto por datos y marcas de delimitación. Las marcas pueden ser:

marcas de comienzo <seccion>
marcas de final </seccion>
marcas de elemento vacío <imagen/>
referencia de entidades &encabezado1;
referencia de caracteres &#33;
comentarios <!-- comentario -->
declaración de tipos  
delimitadores sección CDATA <![CDATA[el contenido de un CDATA no se analiza]]>
instrucciones de procesamiento <!ELEMENT parrafo (#PCDATA)>

El texto que no coincida con una marca será interpretado como datos del documento.

El carácter ampersand (&) y el signo menor que (<) pueden aparecer sólo como delimitadores de marca o dentro de un comentario, una instrucción o una sección CDATA (o dentro de un SystemLiteral).

Para que aparezcan como datos, deben ser usadas las secuencias de escape "&amp;" y "<lt;" respectivamente.

[Estas entidades deben ser definidas por los analizadores (parsers) aunque no estén declaradas como tales en el DTD]

Para permitir que los valores de algunos atributos contengan comillas simples (‘) o dobles ("), pueden ser utilizadas las secuencias de escape "&apos;" y """ respectivamente.

[14] CharData ::= [^<&]* - ([^<&]* ']]>' [^<&]*)

[Es decir, cualquier secuencia de caracteres que no contenga ‘<’, ni ‘&’, ni la secuencia ‘]]>’ (utilizada para cerrar las secciones CDATA)].

 

Comentarios

Los comentarios pueden aparecer en cualquier punto del documento, fuera de otra marca. Por compatibilidad, no debe aparecer la cadena "--" dentro de un comentario

[15] Comment ::= '<!--' ((Char - '-') | ('-' (Char - '-')))* '-->'

<!-- Ejemplo de un comentario -->

El texto de un comentario no forma parte del texto del documento. Los procesadores XML pueden (aunque no es obligatorio) incorporar una opción que permita a las aplicaciones trabajar con el texto incluido en los comentarios.

 

Instrucciones de procesamiento (PI’s)

Permiten a los documentos almacenar instrucciones que pueden ser utilizadas por las aplicaciones (como las marcas de escape de JavaScript, PHP, etc... para HTML).

[16] PI ::= '<?' PITarget (S (Char* - (Char* '?>' Char*)))? '?>'
[17] PITarget ::= Name - (('X' | 'x') ('M' | 'm') ('L' | 'l'))        

Las instrucciones de procesamiento no forman parte de los datos de documento, sino que deben ser pasadas a la aplicación.

Las instrucciones de procesamiento comienzan con un destinatario (PITarget) que identifica a la aplicación a la que se dirige la instrucción. Los nombres con la forma ‘xml’ están reservados.

El mecanismo de ‘notación’ XML puede ser utilizado para la declaración formal de los destinatarios (PITarget).

Ejemplo de instrucción de procesamiento:

<saludo> Estimado
 <?php insertaNuevoDestinatario('Sr. Gómez')?>
 <destinatario>Sr. Gómez  </destinatario>
</saludo>

 

Secciones CDATA

Son usadas como bloques de escape que contienen texto que podría ser confundido con marcas de formato en cualquier otra sección. Las secciones CDATA comienzan con la cadena "<![CDATA[" y finalizan con la cadena "]]>"

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

Una vez dentro de una sección CDATA, el analizador (parser) sólo debería reconocer como marcador la cadena de finalización CDEnd. (Por lo tanto pueden aparecer todos los caracteres (sin secuencia de escape) excepto la secuencia ‘]]>’ como parte del texto).

Las secciones CDATA no pueden ser anidadas. (La marca <![CDATA[ sería interpretada como texto y la marca de finalización de la sección CDATA interna como una marca de finalización errónea).

Ejemplo de sección CDATA:

<contenido>
 <![CDATA[
   El contenido de un <![CDATA[ aparece tal cual
 ]]>
</contenido>

 

Enlaces patrocinados:
Viajar por Extremadura - Webs amigas de ViajarPorExtremadura.com - Casas rurales, hoteles y alojamiento cerca de Mérida - Badajoz - Extremadura - Casas rurales, apartamentos, hoteles y alojamiento en la Sierra de Gata - Cáceres - Extremadura

Felipe Fernández Perera : Google+