De Wikipedia, la enciclopedia libre
  (Redirigido desde Definición de tipo de documento )
Saltar a navegación Saltar a búsqueda

Una definición de tipo de documento ( DTD ) es un conjunto de declaraciones de marcado que definen un tipo de documento para un lenguaje de marcado de familia SGML ( GML , SGML , XML , HTML ).

Una DTD define los bloques de construcción válidos de un documento XML. Define la estructura del documento con una lista de elementos y atributos validados. Una DTD se puede declarar en línea dentro de un documento XML o como una referencia externa. [1]

XML utiliza un subconjunto de SGML DTD.

A partir de 2009 , los nuevos espacios de nombres XML sea conscientes lenguajes de esquema (como el esquema XML del W3C y la ISO RELAX NG ) han reemplazado en gran medida DTD. Se está desarrollando una versión de DTD con reconocimiento de espacio de nombres como Parte 9 de ISO DSDL . Las DTD persisten en aplicaciones que necesitan caracteres de publicación especiales, como las referencias de entidades de caracteres XML y HTML , que se derivan de conjuntos más grandes definidos como parte del esfuerzo estándar ISO SGML .

Asociación de DTD con documentos [ editar ]

Una DTD se asocia a un documento XML o SGML mediante una declaración de tipo de documento (DOCTYPE). El DOCTYPE aparece en el fragmento sintáctico doctypedecl cerca del comienzo de un documento XML. [2] La declaración establece que el documento es una instancia del tipo definido por la DTD referenciada.

Los DOCTYPE hacen dos tipos de declaración:

  • un subconjunto externo opcional
  • un subconjunto interno opcional .

Las declaraciones en el subconjunto interno forman parte del DOCTYPE en el propio documento. Las declaraciones del subconjunto externo se encuentran en un archivo de texto separado. Se puede hacer referencia al subconjunto externo mediante un identificador público y / o un identificador de sistema . Es posible que no se requiera que los programas para leer documentos lean el subconjunto externo.

Cualquier documento SGML o XML válido que haga referencia a un subconjunto externo en su DTD, o cuyo cuerpo contenga referencias a entidades externas analizadas declaradas en su DTD (incluidas aquellas declaradas dentro de su subconjunto interno ), solo se puede analizar parcialmente pero no se puede validar completamente mediante la validación. Analizadores SGML o XML en su modo independiente (esto significa que estos analizadores de validación no intentan recuperar estas entidades externas y su texto de reemplazo no es accesible).

Sin embargo, dichos documentos todavía se pueden analizar por completo en el modo no independiente de validación de analizadores, lo que indica un error si no puede ubicar estas entidades externas con su identificador público (FPI) o identificador del sistema (un URI) especificado , o son inaccesibles . (Las notaciones declaradas en la DTD también hacen referencia a entidades externas, pero estas entidades no analizadas no son necesarias para la validación de documentos en el modo independiente de estos analizadores: la validación de todas las entidades externas a las que hacen referencia las notaciones se deja a la aplicación utilizando SGML o Analizador XML). No validador analizadores puede finalmente intentar localizar estas entidades externas en el no-modo independiente (interpretando parcialmente la DTD solo para resolver sus entidades analizables declaradas), pero no valida el modelo de contenido de estos documentos.

Ejemplos [ editar ]

El siguiente ejemplo de un DOCTYPE contiene identificadores públicos y del sistema:

<! DOCTYPE  html  PUBLIC  "- // W3C // DTD XHTML 1.0 Transitional // EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >

Todos los documentos HTML 4.01 se ajustan a uno de los tres DTD SGML. Los identificadores públicos de estos DTD son constantes y son los siguientes:

Los identificadores del sistema de estos DTD, si están presentes en el DOCTYPE, son referencias de URI . Un identificador de sistema generalmente apunta a un conjunto específico de declaraciones en una ubicación que se puede resolver. SGML permite mapear identificadores públicos a identificadores de sistema en catálogos que están disponibles opcionalmente para los resolutores de URI utilizados por el software de análisis de documentos .

Este DOCTYPE solo puede aparecer después de la declaración XML opcional y antes del cuerpo del documento, si la sintaxis del documento se ajusta a XML. Esto incluye documentos XHTML :

<? xml version = "1.0" encoding = "utf-8"?> <! DOCTYPE html PUBLIC "- // W3C // DTD XHTML 1.0 Transitional // EN" "http://www.w3.org/TR/ xhtml1 / DTD / xhtml1-transitional.dtd "> <! - el cuerpo del documento XHTML comienza aquí -> <html  xmlns = " http://www.w3.org/1999/xhtml " > ...</html>

También se puede proporcionar un subconjunto interno adicional después del subconjunto externo:

<? xml version = "1.0" encoding = "utf-8"?> <! DOCTYPE html PUBLIC "- // W3C // DTD XHTML 1.0 Transitional // EN" "http://www.w3.org/TR/ xhtml1 / DTD / xhtml1-transitional.dtd "[  <! - se puede incrustar un subconjunto interno aquí ->]><! - el cuerpo del documento XHTML comienza aquí -> <html  xmlns = "http://www.w3.org/1999/xhtml" > ...</html>

Alternativamente, solo se puede proporcionar el subconjunto interno:

<? xml version = "1.0" encoding = "utf-8"?> <! DOCTYPE html [  <! - se puede incrustar un subconjunto interno aquí ->]><! - el cuerpo del documento XHTML comienza aquí -> <html  xmlns = "http://www.w3.org/1999/xhtml" > ...</html>

Finalmente, la definición del tipo de documento puede no incluir ningún subconjunto; en ese caso, solo especifica que el documento tiene un único elemento de nivel superior (este es un requisito implícito para todos los documentos XML y HTML válidos, pero no para los fragmentos de documento o para todos los documentos SGML, cuyos elementos de nivel superior pueden ser diferentes del elemento raíz implícito), e indica el nombre de tipo del elemento raíz:

<? xml version = "1.0" encoding = "utf-8"?> <! DOCTYPE html> <! - el cuerpo del documento XHTML comienza aquí -> <html  xmlns = "http://www.w3.org/ 1999 / xhtml " > ...</html>

Declaraciones de marcado [ editar ]

Los DTD describen la estructura de una clase de documentos mediante declaraciones de lista de atributos y elementos. Las declaraciones de elementos nombran el conjunto permitido de elementos dentro del documento y especifican si los elementos declarados y las series de datos de caracteres pueden estar contenidos dentro de cada elemento y cómo. Las declaraciones de lista de atributos nombran el conjunto permitido de atributos para cada elemento declarado, incluido el tipo de cada valor de atributo, si no un conjunto explícito de valores válidos.

Las declaraciones de marcado DTD declaran qué tipos de elementos , listas de atributos , entidades y notaciones están permitidos en la estructura de la clase correspondiente de documentos XML. [3]

Declaraciones de tipo de elemento [ editar ]

Una declaración de tipo de elemento define un elemento y su posible contenido. Un documento XML válido contiene solo elementos que están definidos en la DTD.

Varias palabras clave y caracteres especifican el contenido de un elemento:

  • EMPTY para especificar que el elemento definido no admite contenido, es decir, no puede tener elementos hijos, ni siquiera elementos de texto (si hay espacios en blanco, se ignoran);
  • ANY por especificar que el elemento definido permite cualquier contenido, sin restricción, es decir, que puede tener cualquier número (incluido ninguno) y tipo de elementos secundarios (incluidos los elementos de texto);
  • o una expresión, especificando los únicos elementos permitidos como hijos directos en el contenido del elemento definido; este contenido puede ser:
    • un contenido mixto , lo que significa que el contenido puede incluir al menos un elemento de texto y cero o más elementos con nombre, pero su orden y número de ocurrencias no puede ser restringido; esto puede ser:
      • ( #PCDATA ): históricamente significa datos de caracteres analizados , esto significa que solo se permite un elemento de texto en el contenido (no se permite cuantificador);
      • ( #PCDATA | ''element name'' | ... )*: una opción limitada (en una lista exclusiva entre paréntesis y separada por " |" caracteres de barra vertical y terminada por el *cuantificador " " requerido ) de dos o más elementos secundarios (incluidos solo los elementos de texto o los elementos con nombre especificados) se puede usar en cualquier orden y número de ocurrencias en el contenido.
    • un contenido de elemento , lo que significa que no debe haber elementos de texto en los elementos secundarios del contenido (todos los espacios en blanco codificados entre los elementos secundarios se ignoran, al igual que los comentarios). Dicho contenido de elemento se especifica como partícula de contenido en una variante de la forma Backus-Naur sin símbolos terminales y nombres de elementos como símbolos no terminales. El contenido del elemento consta de:
      • una partícula de contenido puede ser el nombre de un elemento declarado en la DTD o una lista de secuencia o lista de opciones . Puede ir seguido de un cuantificador opcional .
        • una lista de secuencia significa una lista ordenada (especificada entre paréntesis y separada por un ,carácter de coma " ") de una o más partículas de contenido : todas las partículas de contenido deben aparecer sucesivamente como hijos directos en el contenido del elemento definido, en la posición especificada y orden relativo;
        • una lista de opciones significa una lista mutuamente excluyente (especificada entre paréntesis y separada por un |carácter de barra vertical) de dos o más partículas de contenido : solo una de estas partículas de contenido puede aparecer en el contenido del elemento definido en la misma posición.
      • Un cuantificador es un carácter único que sigue inmediatamente al elemento especificado al que se aplica, para restringir el número de apariciones sucesivas de estos elementos en la posición especificada en el contenido del elemento; puede ser:
        • + para especificar que debe haber una o más ocurrencias del artículo; el contenido efectivo de cada ocurrencia puede ser diferente;
        • * para especificar que se permite cualquier número (cero o más) de ocurrencias - el elemento es opcional y el contenido efectivo de cada ocurrencia puede ser diferente;
        • ? para especificar que no debe haber más de una ocurrencia - el ítem es opcional;
        • Si no hay cuantificador, el elemento especificado debe aparecer exactamente una vez en la posición especificada en el contenido del elemento.

Por ejemplo:

<! ELEMENT  html  ( cabeza ,  cuerpo ) > <! ELEMENT  p  ( #PCDATA  |  p  |  ul  |  dl  |  tabla  |  h1 | h2 | h3 ) * >

Declaraciones tipo de elemento son ignorados por no validador SGML y XML analizadores (en la que los casos, se aceptan todos los elementos en cualquier orden, y en cualquier número de ocurrencias en el documento analizado), pero estas declaraciones todavía se comprueba la forma y validez.

Declaraciones de lista de atributos [ editar ]

Una lista de atributos especifica para un tipo de elemento dado la lista de todos los atributos posibles asociados con ese tipo. Para cada atributo posible, contiene:

  • el nombre declarado del atributo,
  • su tipo de datos (o una enumeración de sus posibles valores),
  • y su valor predeterminado. [4]

Por ejemplo:

<! ATTLIST  img  src  CDATA  #REQUIRED  ID  ID  #IMPLIED  tipo  CDATA  #FIXED  "verdadero"  de impresión  (  |  no )  "sí" >

A continuación, se muestran algunos tipos de atributos compatibles con SGML y XML:

CDATA
este tipo significa datos de caracteres e indica que el valor efectivo del atributo puede ser cualquier valor textual, a menos que el atributo se especifique como fijo (los comentarios en la DTD pueden documentar valores que son efectivamente aceptados, pero la sintaxis de la DTD no permite tal especificación precisa);
ID
el valor efectivo del atributo debe ser un identificador válido, y se usa para definir y anclar al elemento actual el destino de las referencias usando este identificador definido (incluso como identificadores de fragmentos de documentos que se pueden especificar al final de un URI después de un " #" firmar); es un error si distintos elementos en el mismo documento definen el mismo identificador; la restricción de unicidad también implica que el identificador en sí no tiene otra semántica y que los identificadores deben tratarse como opacos en las aplicaciones; XML también predefine el pseudoatributo estándar " xml:id" con este tipo, sin necesidad de ninguna declaración en el DTD, por lo que la restricción de unicidad también se aplica a estos identificadores definidos cuando se especifican en cualquier lugar de un documento XML.
IDREF o IDREFS
el valor efectivo del atributo solo puede ser un identificador válido (o una lista separada por espacios de dichos identificadores) y debe hacer referencia al elemento único definido en el documento con un atributo declarado con el tipo IDen la DTD (o el elemento único definido en un documento XML con un pseudo-atributo " xml:id") y cuyo valor efectivo es el mismo identificador;
NMTOKEN o NMTOKENS
el valor efectivo del atributo solo puede ser un token de nombre válido (o una lista separada por espacios de dichos tokens de nombre), pero no está restringido a un identificador único dentro del documento; este nombre puede llevar semántica suplementaria y dependiente de la aplicación y puede requerir restricciones de denominación adicionales, pero esto está fuera del alcance de la DTD;
ENTITY o ENTITIES
el valor efectivo del atributo solo puede ser el nombre de una entidad externa sin analizar (o una lista separada por espacios de dichos nombres), que también debe declararse en la declaración del tipo de documento; este tipo no es compatible con analizadores HTML, pero es válido en SGML y XML 1.0 o 1.1 (incluidos XHTML y SVG);
(''value1''|...)
el valor efectivo del atributo solo puede ser uno de la lista enumerada (especificado entre paréntesis y separado por un |carácter de barra " ") de valores textuales, donde cada valor en la enumeración posiblemente se especifique entre comillas 'simples 'o "dobles "si no es un token de nombre simple;
NOTATION (''notation1''|...)
el valor efectivo del atributo solo puede ser cualquiera de la lista enumerada (especificado entre paréntesis y separado por un " |" carácter de barra vertical) de nombres de notación, donde cada nombre de notación en la enumeración también debe declararse en la declaración del tipo de documento; este tipo no es compatible con analizadores HTML, pero es válido en SGML y XML 1.0 o 1.1 (incluidos XHTML y SVG).

Un valor predeterminado puede definir si un atributo debe aparecer ( #REQUIRED) o no ( #IMPLIED), o si tiene un valor fijo ( #FIXED), o qué valor debe usarse como valor predeterminado ("…") en caso de que el atributo dado se deje fuera en una etiqueta XML.

Los analizadores XML y SGML no validantes ignoran las declaraciones de la lista de atributos (en cuyo caso se acepta cualquier atributo dentro de todos los elementos del documento analizado), pero estas declaraciones aún se comprueban para verificar que estén bien formadas y sean válidas.

Declaraciones de entidad [ editar ]

Una entidad es similar a una macro . La declaración de entidad le asigna un valor que se retiene en todo el documento. Un uso común es tener un nombre más reconocible que una referencia de carácter numérico para un carácter desconocido. [5] Las entidades ayudan a mejorar la legibilidad de un texto XML. En general, hay dos tipos: internos y externos.

  • Las entidades internas (analizadas) asocian un nombre con cualquier contenido textual arbitrario definido en su declaración (que puede estar en el subconjunto interno o en el subconjunto externo de la DTD declarada en el documento). Cuando se encuentra una referencia de entidad con nombre en el resto del documento (incluido en el resto de la DTD), y si este nombre de entidad se ha definido efectivamente como una entidad analizada, la referencia en sí se reemplaza inmediatamente por el contenido textual definido en la entidad analizada y el análisis continúa dentro de este texto de reemplazo.
    • Las entidades de carácter con nombre predefinidas son similares a las entidades internas: 5 de ellas, sin embargo, se tratan especialmente en todos los analizadores SGML, HTML y XML. Estas entidades son un poco diferentes de las entidades analizadas normales, porque cuando se encuentra una referencia de entidad de carácter con nombre en el documento, la referencia también se reemplaza inmediatamente por el contenido de carácter definido en la entidad, pero el análisis continúa despuésel texto de reemplazo, que se inserta inmediatamente literalmente en el token analizado actualmente (si dicho carácter está permitido en el valor textual de ese token). Esto permite que algunos caracteres necesarios para la sintaxis principal de HTML o XML se escapen de su función sintáctica especial (en particular, "&", que está reservado para referencias de entidades iniciales, "<" o ">" que delimitan las etiquetas de marcado, y comillas "dobles" o "simples", que delimitan los valores de atributos y definiciones de entidades). Las entidades de caracteres predefinidas también incluyen referencias de caracteres numéricos que se manejan de la misma manera y también se pueden usar para escapar de los caracteres que representan o para eludir limitaciones en el repertorio de caracteres admitido por la codificación del documento.
    • En perfiles básicos para SGML o en documentos HTML, la declaración de entidades internas no es posible (porque los subconjuntos de DTD externos no se recuperan y los subconjuntos de DTD internos no son compatibles con estos perfiles básicos).
    • En cambio, los estándares HTML predefinen un gran conjunto de varios cientos de entidades de caracteres con nombre, que aún pueden manejarse como entidades analizadas estándar definidas en la DTD utilizada por el analizador.
  • Las entidades externas se refieren a objetos de almacenamiento externo. Simplemente se declaran con un nombre único en el documento y se definen con un identificador público (un FPI) y / o un identificador del sistema (interpretado como un URI ) que especifica dónde está la fuente de su contenido. Existen, de hecho, en dos variantes:
    • entidades externas analizadas (generalmente definidas con un identificador de SISTEMA que indica el URI de su contenido) que no están asociadas en su definición a una anotación con nombre, en cuyo caso los analizadores XML o SGML de validación recuperan su contenido y lo analizan como si estuvieran declarados como entidades internas (la entidad externa que contiene su texto de reemplazo efectivo);
    • entidades externas sin analizar que se definen y asocian con un nombre de anotación, en cuyo caso se tratan como referencias opacas y se señalan como tales a la aplicación mediante el analizador SGML o XML: su interpretación, recuperación y análisis se deja a la aplicación, según los tipos de anotaciones que admite (consulte la siguiente sección sobre anotaciones y ejemplos de entidades externas sin analizar).
    • Las entidades externas no son compatibles con perfiles básicos para SGML o en documentos HTML, pero son válidas en implementaciones completas de SGML y en XML 1.0 o 1.1 (incluyendo XHTML y SVG, incluso si no son estrictamente necesarias en esos tipos de documentos).

Un ejemplo de declaraciones de entidades internas (aquí en un subconjunto DTD interno de un documento SGML) es:

<! DOCTYPE  sgml  [  <! ELEMENT  sgml  ANY >  <! ENTITY  %  std  "Standard SGML" >  <! ENTITY  %  signature  "& # x2014; & author ;." >  <! ENTITY  %  pregunta  "¿Por qué no puedo publicar mis libros directamente en% std ;?" >  <! ENTITY  %  autor  "William Shakespeare" > ]>
<sgml> & question; & signature; </sgml>

Las entidades internas pueden definirse en cualquier orden, siempre y cuando no estén referenciadas y analizadas en la DTD o en el cuerpo del documento, en su orden de análisis: es válido incluir una referencia a una entidad aún indefinida dentro del contenido. de una entidad analizada, pero no es válido incluir en cualquier otro lugar cualquier referencia de entidad nombrada antes de que esta entidad se haya definido completamente, incluidas todas las demás entidades internas a las que se hace referencia en su contenido definido (esto también evita las definiciones circulares o recursivas de entidades internas). Este documento se analiza como si fuera:

<! DOCTYPE  sgml  [  <! ELEMENT  sgml  ANY >  <! ENTITY  %  std  "Standard SGML" >  <! ENTITY  %  signature  "- & author;" >  <! ENTITY  %  pregunta  "¿Por qué no puedo publicar mis libros directamente en SGML estándar?" >  <! ENTITY  %  autor  "William Shakespeare" > ]>
<sgml> ¿Por qué no puedo publicar mis libros directamente en SGML estándar? - William Shakespeare. </sgml>

La referencia a la entidad interna "autor" no se sustituye en el texto de reemplazo de la entidad interna "firma". En su lugar, se reemplaza solo cuando la referencia de entidad "firma" se analiza dentro del contenido del elemento "sgml", pero solo mediante analizadores de validación (los analizadores de no validación no sustituyen las referencias de entidad que aparecen dentro del contenido del elemento o dentro de los valores de atributo, en el cuerpo del documento.

Esto es posible porque el texto de reemplazo especificado en las definiciones de entidad interna permite una distinción entre referencias de entidad de parámetro (que se introducen con el carácter "%" y cuyo reemplazo se aplica al contenido de DTD analizado) y referencias de entidad general (que son introducidas por el "&" y cuyo reemplazo se retrasa hasta que se analizan y validan eficazmente). El carácter "%" para introducir referencias a entidades de parámetros en la DTD pierde su función especial fuera de la DTD y se convierte en un carácter literal.

Sin embargo, las referencias a entidades de caracteres numéricos predefinidos se sustituyen dondequiera que se produzcan, sin necesidad de un analizador de validación (solo se introducen mediante el carácter "&").

Declaraciones de notación [ editar ]

Las notaciones se utilizan en SGML o XML. Proporcionan una referencia completa a entidades externas no analizadas cuya interpretación se deja a la aplicación (que las interpreta directamente o recupera la entidad externa por sí mismas), asignándoles un nombre simple, que se puede utilizar en el cuerpo del documento. Por ejemplo, las notaciones se pueden utilizar para hacer referencia a datos que no son XML en un documento XML 1.1. Por ejemplo, para anotar imágenes SVG para asociarlas con un renderizador específico:

<! NOTATION  type-image-svg  SYSTEM  "image / svg" >

Esto declara el tipo MIME de imágenes externas con este tipo y lo asocia con un nombre de notación "type-image-svg". Sin embargo, los nombres de notación generalmente siguen una convención de nomenclatura que es específica de la aplicación que genera o usa la notación: las notaciones se interpretan como metadatos adicionales cuyo contenido efectivo es una entidad externa y un FPI PÚBLICO, registrado en los catálogos utilizados por XML o Analizadores SGML, o un SYSTEM URI, cuya interpretación depende de la aplicación (en este caso, un tipo MIME, interpretado como un URI relativo, pero podría ser un URI absoluto para un renderizador específico, o un URN que indica un identificador de objeto específico del sistema operativo, como un UUID).

El nombre de la notación declarado debe ser único dentro de toda la declaración del tipo de documento, es decir, tanto en el subconjunto externo como en el interno, al menos para cumplir con XML. [6] [7]

Las notaciones se pueden asociar a entidades externas no analizadas incluidas en el cuerpo del documento SGML o XML. El parámetro PUBLICo SYSTEMde estas entidades externas especifica el FPI y / o el URI donde se encuentran los datos no analizados de la entidad externa, y el NDATAparámetro adicional de estas entidades definidas especifica la notación adicional (es decir, efectivamente el tipo MIME aquí). Por ejemplo:

<! DOCTYPE  sgml  [  <! ELEMENT  sgml  ( img ) * > <! ELEMENTO  img  EMPTY >  <! ATTLIST  img  data  ENTITY  #IMPLIED > <! ENTITY  example1SVG  SYSTEM  "example1.svg"  NDATA  example1SVG-rdf >  <! NOTATION  example1SVG-rdf  SYSTEM  "example1.svg.rdf" > ]>
<sgml>  <img  data = "example1SVG"  /> </sgml>

Dentro del cuerpo del documento SGML, estas entidades externas referenciadas (cuyo nombre se especifica entre "&" y ";") no se reemplazan como las entidades con nombre habituales (definidas con un valor CDATA), sino que se dejan como tokens distintos sin analizar que pueden ser utilizado como el valor de un atributo de elemento (como arriba) o dentro del contenido del elemento, siempre que la DTD permita tales entidades externas en el tipo de contenido declarado de elementos o en el tipo declarado de atributos (aquí el ENTITYtipo para el dataatributo ), o el analizador SGML no está validando el contenido.

Las notaciones también pueden asociarse directamente a elementos como metadatos adicionales, sin asociarlos a otra entidad externa, dando sus nombres como posibles valores de algunos atributos adicionales (también declarados en el DTD dentro de la declaración del elemento). Por ejemplo:<!ATTLIST ...>

<! DOCTYPE  sgml  [  <! ELEMENT  sgml  ( img ) * >  <! -  el valor del atributo "tipo" opcional solo se puede establecer en esta notación.  ->  <! ATTLIST  sgml  type  NOTATION  (  tipo específico del proveedor  )  #IMPLIED > <! ELEMENT  img  ANY >  <! - el contenido opcional solo puede ser analizable SGML o datos XML ->  <! -  El valor del atributo "title" opcional debe poder analizarse como texto.  El valor del atributo "datos" opcional se establece en una entidad externa sin analizar.  El valor del atributo "tipo" opcional solo puede ser una de las dos notaciones.  ->  <! ATTLIST  img  título  CDATA  #IMPLIED  datos  ENTIDAD  #IMPLIED  tipo  NOTACION  (  tipo-imagen-SVG  |  tipo de imagen gif  )  #IMPLIED > <! - Las  notaciones hacen referencia a entidades externas y se pueden establecer en los atributos de "tipo" anteriores,  o deben ser referenciadas por cualquier entidad externa definida que no se pueda analizar.  ->  <! NOTATION  type-image-svg  PUBLIC  "- // W3C // DTD SVG 1.1 // EN"  "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd" >  <! NOTATION  type-image-gif  PUBLIC  "image / gif" >  <! NOTATION  type-vendor-specific  PUBLIC  "application / VND.specific + sgml" > <! ENTITY  example1SVGTitle  "Título de example1.svg" >  <! - entidad interna analizada ->  <! ENTITY  example1SVG  SYSTEM  "example1.svg" >  <! - entidad externa analizada ->  <! ENTITY  example1GIFTitle  "Título de example1.gif " >  <! - entidad interna analizada ->  <! ENTITY  example1GIF  SYSTEM  " example1.gif "  NDATA  type-image-gif >  <! - entidad externa no analizada -> ]>
<sgml  type = "type-vendor-specific" >  <! - una imagen SVG se puede analizar como texto SGML o XML válido ->  <img  title = "& example1SVGTitle;"  type = "type-image-svg" > & example1SVG; </img> <! - también se puede hacer referencia a ella como una entidad externa sin analizar ->  <img  title = "& example1SVGTitle;"  datos = "ejemplo1SVG"  /> <! - una imagen GIF no se puede analizar y solo se puede hacer referencia a ella como una entidad externa ->  <img  title = "& example1GIFTitle;"  data = "ejemplo1GIF"  /> </sgml>

El ejemplo anterior muestra una notación llamada "type-image-svg" que hace referencia al FPI público estándar y al identificador del sistema (el URI estándar) de un documento SVG 1.1, en lugar de especificar solo un identificador del sistema como en el primer ejemplo (que fue un URI relativo interpretado localmente como un tipo MIME). Se hace referencia a esta anotación directamente dentro del atributo "type" sin analizar del elemento "img", pero su contenido no se recupera. También declara otra notación para una aplicación específica del proveedor, para anotar el elemento raíz "sgml" en el documento. En ambos casos, la notación declarada named se usa directamente en un atributo "type" declarado, cuyo contenido se especifica en la DTD con el atributo type "NOTATION" (este atributo "type" se declara para el elemento "sgml",así como para el elemento "img").

Sin embargo, el atributo "title" del elemento "img" especifica la entidad interna "example1SVGTitle" cuya declaración no define una anotación, por lo que se analiza mediante analizadores de validación y el texto de reemplazo de la entidad es "Título de example1.svg".

El contenido del elemento "img" hace referencia a otra entidad externa "example1SVG" cuya declaración tampoco define una notación, por lo que también se analiza mediante analizadores de validación y el texto de reemplazo de la entidad se ubica mediante su identificador de SISTEMA definido "example1.svg" ( también se interpreta como un URI relativo). El contenido efectivo del elemento "img" será el contenido de este segundo recurso externo. La diferencia con la imagen GIF es que la imagen SVG se analiza dentro del documento SGML, de acuerdo con las declaraciones en el DTD, donde la imagen GIF solo se hace referencia como un objeto externo opaco (que no se puede analizar con SGML) a través de su " data "atributo (cuyo tipo de valor es una ENTIDAD opaca).

Solo se puede especificar un nombre de notación en el valor de los atributos ENTITY (no hay soporte en SGML, XML 1.0 o XML 1.1 para múltiples nombres de notación en la misma ENTITY externa declarada, por lo que se necesitan atributos separados). Sin embargo, se puede hacer referencia a múltiples entidades externas (en una lista de nombres separados por espacios) en atributos declarados con el tipo ENTITIES, y donde cada entidad externa nombrada también se declara con su propia notación).

Las notaciones también son completamente opacas para los analizadores XML y SGML, por lo que no se diferencian por el tipo de entidad externa a la que pueden hacer referencia (para estos analizadores solo tienen un nombre único asociado a un identificador público (un FPI) y / o un identificador del sistema (un URI)).

Algunas aplicaciones (pero no los analizadores XML o SGML) también permiten hacer referencia a notaciones indirectamente nombrándolas en el "URN:''name''"valor de un atributo CDATA estándar, en cualquier lugar donde se pueda especificar un URI. Sin embargo, este comportamiento es específico de la aplicación y requiere que la aplicación mantenga un catálogo de URN conocidos para resolverlos en las notaciones que se han analizado en un analizador SGML o XML estándar. Este uso permite que las notaciones se definan solo en un DTD almacenado como una entidad externa y referenciado solo como el subconjunto externo de documentos, y permite que estos documentos sigan siendo compatibles con la validación de analizadores XML o SGML que no tienen soporte directo para notaciones.

Las notaciones no se utilizan en HTML, ni en perfiles básicos para XHTML y SVG, porque:

  • Todas las entidades externas utilizadas por estos tipos de documentos estándar están referenciadas por atributos simples, declarados con el tipo CDATA en su DTD estándar (como el atributo "href" de un elemento de anclaje "a" o el atributo "src" de una imagen " img ", cuyos valores se interpretan como un URI, sin necesidad de ningún catálogo de identificadores públicos, es decir, FPI conocido)
  • Todas las entidades externas para metadatos adicionales están referenciadas por:
    • Atributos adicionales (como tipo , que indica el tipo MIME de la entidad externa, o el atributo charset , que indica su codificación)
    • Elementos adicionales (como enlace o meta en HTML y XHTML) dentro de sus propios atributos
    • Seudoatributos estándar en XML y XHTML (como xml: lang o xmlns y xmlns: * para declaraciones de espacio de nombres).

Incluso al validar analizadores SGML o XML 1.0 o XML 1.1, los analizadores mismos no recuperan automáticamente las entidades externas a las que hace referencia un FPI y / o URI en notaciones declaradas. En su lugar, estos analizadores solo proporcionan a la aplicación el FPI y / o URI analizados asociados a las notaciones que se encuentran en el documento SGML o XML analizado, y con una función para un diccionario que contiene todos los nombres de notación declarados en el DTD; Estos analizadores de validación también verifican la unicidad de las declaraciones de nombres de notación e informan un error de validación si algunos nombres de notación se utilizan en cualquier parte de la DTD o en el cuerpo del documento pero no se declaran:

  • Si la aplicación no puede usar ninguna notación (o si su FPI y / o URI son desconocidos o no son compatibles con su catálogo local), estas notaciones pueden ser ignoradas silenciosamente por la aplicación o la aplicación podría indicar un error.
  • De lo contrario, las aplicaciones deciden por sí mismas cómo interpretarlas, luego si las entidades externas deben recuperarse y luego analizarse por separado.
  • Las aplicaciones pueden entonces señalar un error, si tal interpretación, recuperación o análisis por separado falla.
  • Las notaciones no reconocidas que pueden hacer que una aplicación indique un error no deben bloquear la interpretación del documento validado que las usa.

DTD XML y validación de esquemas [ editar ]

La sintaxis de XML DTD es uno de varios lenguajes de esquema XML . Sin embargo, muchos de los lenguajes de esquema no reemplazan completamente a XML DTD. En particular, la DTD XML permite definir entidades y notaciones que no tienen equivalentes directos en XML sin DTD (porque las entidades internas y las entidades externas analizables no forman parte de los lenguajes de esquema XML, y porque otras entidades y notaciones externas no analizadas no tienen asignaciones equivalentes simples en la mayoría de los lenguajes de esquema XML).

La mayoría de los lenguajes de esquema XML son sólo sustitutos de las declaraciones de elementos y lista de atributos declaraciones, de tal manera que se hace posible a los documentos XML analizan con no validar los analizadores XML (si el único propósito del subconjunto DTD externa fue definir el esquema). Además, los documentos para estos lenguajes de esquema XML deben analizarse por separado, por lo que validar el esquema de documentos XML en modo autónomo puro no es realmente posible con estos lenguajes: la declaración del tipo de documento sigue siendo necesaria para al menos identificar (con un catálogo XML ) el esquema utilizado en el documento XML analizado y que está validado en otro idioma.

Un error común sostiene que un analizador XML no validado no tiene que leer declaraciones de tipo de documento, cuando de hecho, las declaraciones de tipo de documento aún deben escanearse para la sintaxis correcta, así como la validez de las declaraciones, y el analizador aún debe analizar todas las entidades. declaraciones en el subconjunto interno y sustituya los textos de reemplazo de las entidades internas que aparecen en cualquier lugar de la declaración del tipo de documento o en el cuerpo del documento.

A no validador analizador puede, sin embargo, elegir no leer parsable entidades externas (incluyendo el subconjunto externo ), y no tiene que cumplir las restricciones modelo de contenido definidos en las declaraciones de elementos y en las declaraciones de lista de atributos.

Si el documento XML depende de entidades externas analizables (incluido el subconjunto externo especificado , o entidades externas analizables declaradas en el subconjunto interno ), debe afirmar standalone="no"en su declaración XML . La DTD de validación puede identificarse mediante catálogos XML para recuperar su subconjunto externo especificado .

En el siguiente ejemplo, el documento XML se declara con standalone="no"porque tiene un subconjunto externo en su declaración de tipo de documento:

<? xml version = "1.0" encoding = "UTF-8" standalone = "no"?> <! DOCTYPE people_list SYSTEM "example.dtd"> <people_list  />

Si la declaración del tipo de documento XML incluye cualquier identificador de SISTEMA para el subconjunto externo, no se puede procesar de forma segura como independiente: el URI debe recuperarse; de ​​lo contrario, puede haber entidades de carácter con nombre desconocido cuya definición puede ser necesaria para analizar correctamente el XML efectivo sintaxis en el subconjunto interno o en el cuerpo del documento (el análisis sintáctico XML se realiza normalmente después de la sustitución de todas las entidades nombradas, excluyendo las cinco entidades que están predefinidas en XML y que se sustituyen implícitamente después de analizar el documento XML en tokens léxicos). Si solo incluye cualquier identificador PÚBLICO, puede procesarse como independiente, si el procesador XML conoce este identificador PÚBLICO en su catálogo local desde donde puede recuperar una entidad DTD asociada.

Ejemplo de esquema de DTD XML [ editar ]

Un ejemplo de una DTD XML externa muy simple para describir el esquema de una lista de personas podría consistir en:

<! ELEMENT  people_list  ( persona ) * > <! ELEMENT  person  ( nombre ,  fecha de nacimiento ?,  Género ?,  Número de seguridad social ?) > <! ELEMENT  name  ( #PCDATA ) > <! ELEMENT  birthdate  ( #PCDATA ) > <! ELEMENT  gender  ( # PCDATA ) > <! ELEMENT número de  seguridad social  ( #PCDATA ) >

Tomando esta línea por línea:

  1. people_listes un nombre de elemento válido y una instancia de dicho elemento contiene cualquier número de personelementos. El *indica que puede haber 0 o más personelementos dentro del people_listelemento.
  2. persones un nombre de elemento válido, y una instancia de dicho elemento contiene un elemento con nombre name, seguido de uno con nombre birthdate(opcional), luego gender(también opcional) y socialsecuritynumber(también opcional). El ?indica que un elemento es opcional. La referencia al namenombre del elemento no tiene ?, por lo que un personelemento debe contener un nameelemento.
  3. name es un nombre de elemento válido y una instancia de dicho elemento contiene "datos de caracteres analizados" (#PCDATA).
  4. birthdate es un nombre de elemento válido y una instancia de dicho elemento contiene datos de caracteres analizados.
  5. gender es un nombre de elemento válido y una instancia de dicho elemento contiene datos de caracteres analizados.
  6. socialsecuritynumber es un nombre de elemento válido y una instancia de dicho elemento contiene datos de caracteres analizados.

A continuación, se muestra un ejemplo de un archivo XML que utiliza y se ajusta a esta DTD. Aquí se hace referencia a la DTD como un subconjunto externo, a través del especificador SYSTEM y un URI. Se asume que podemos identificar la DTD con la referencia URI relativa "ejemplo.dtd"; el "people_list" después de "! DOCTYPE" nos dice que las etiquetas raíz, o el primer elemento definido en la DTD, se llama "people_list":

<? xml version = "1.0" encoding = "UTF-8" standalone = "no"?> <! DOCTYPE people_list SYSTEM "example.dtd"> <people_list>  <person>  <name> Fred Bloggs </name>  <fecha de nacimiento > 2008-11-27 </birthdate>  <gender> Masculino </gender>  </person> </people_list>

Se puede representar esto en un navegador habilitado para XML (como Internet Explorer o Mozilla Firefox ) pegando y guardando el componente DTD anterior en un archivo de texto llamado example.dtd y el archivo XML en un archivo de texto con un nombre diferente, y abriendo el Archivo XML con el navegador. Ambos archivos deben guardarse en el mismo directorio. Sin embargo, muchos navegadores no comprueban que un documento XML se ajuste a las reglas de la DTD; solo se requieren para comprobar que la DTD sea sintácticamente correcta. Por razones de seguridad, también pueden optar por no leer la DTD externa.

El mismo DTD también se puede incrustar directamente en el propio documento XML como un subconjunto interno, encerrándolo entre [corchetes] en la declaración del tipo de documento, en cuyo caso el documento ya no depende de entidades externas y se puede procesar en modo independiente :

<? xml version = "1.0" encoding = "UTF-8" standalone = "yes"?> <! DOCTYPE people_list [  <! ELEMENT people_list (person *)>  <! ELEMENT person (nombre, fecha de nacimiento ?, sexo ?, socialsecuritynumber ?)>  <! ELEMENT name (#PCDATA)>  <! ELEMENT birthdate (#PCDATA)>  <! ELEMENT gender (#PCDATA)>  <! ELEMENT socialsecuritynumber (#PCDATA)>]><PEOPLE_LIST>  <persona>  <nombre> Fred Bloggs </ name>  <fecha de nacimiento> 2008-11-27 </ fecha de nacimiento>  <sexo> Hombre </ género>  </ persona> </ PEOPLE_LIST>

Hay disponibles alternativas a las DTD (para especificar esquemas):

  • XML Schema , también conocido como XML Schema Definition (XSD), ha alcanzado el estado de Recomendación dentro del W3C, [8] y es popular para el uso de XML "orientado a datos" (es decir, no publicación transaccional) debido a su tipificación más fuerte y ida y vuelta más fácil a las declaraciones de Java. [ cita requerida ] La mayor parte del mundo editorial ha descubierto que la complejidad agregada de XSD no les reportaría ningún beneficio particular, [ cita requerida ] por lo que los DTD aún son mucho más populares allí. Una definición de esquema XML es en sí misma un documento XML, mientras que una DTD no lo es.
  • RELAX NG , que también forma parte de DSDL , es un estándar internacional ISO. [9] Es más expresivo que XSD, [ cita requerida ] mientras proporciona una sintaxis más simple, [ cita requerida ] pero el soporte de software comercial ha tardado en llegar.

Seguridad [ editar ]

Una DTD XML se puede utilizar para crear un ataque de denegación de servicio (DoS) definiendo entidades anidadas que se expanden exponencialmente o enviando el analizador XML a un recurso externo que nunca regresa. [10]

Por esta razón, .NET Framework proporciona una propiedad que permite prohibir u omitir el análisis de DTD, [10] y las versiones recientes de las aplicaciones de Microsoft Office (Microsoft Office 2010 y superior) se niegan a abrir archivos XML que contienen declaraciones de DTD.

Ver también [ editar ]

  • Web semántica
  • Comparación de lenguajes de esquemas XML : comparación con otros lenguajes de esquemas XML.
  • Esquema XML (W3C)

Referencias [ editar ]

  1. ^ "Introducción a DTD" .
  2. ^ "doctypedecl" . Lenguaje de marcado extensible (XML) 1.1 . W3C.
  3. ^ Watt, Andrew H. (2002). Sam aprende XML por tu cuenta en 10 minutos . Sams Publishing. ISBN 9780672324710.
  4. ^ Declaración de lista de atributos , especificaciones de lenguaje de marcado extensible (XML) 1.1, W3C.
  5. ^ "Entidades DTD" . Tutorial DTD . W3Schools.
  6. ^ Declaraciones de notación , especificaciones de lenguaje de marcado extensible (XML) 1.0, W3C.
  7. ^ Declaraciones de notación , especificaciones de lenguaje de marcado extensible (XML) 1.1, W3C.
  8. ^ "Parte 1 del esquema XML: estructuras (segunda edición)" . W3C. 2004 . Consultado el 17 de mayo de 2011 .
  9. ^ "ISO / IEC 19757-2: 2008 - tecnología de la información - lenguaje de definición de esquema de documento (DSDL) - parte 2: validación basada en gramática regular - RELAX NG" . ISO . Consultado el 17 de mayo de 2011 .
  10. ↑ a b Bryan Sullivan (noviembre de 2009). "Ataques y defensas de denegación de servicio XML" . Revista MSDN . Consultado el 21 de octubre de 2013 .

Enlaces externos [ editar ]

  • Definición de la declaración de tipo de documento XML de Extensible Markup Language (XML) 1.0 (cuarta edición) en W3.org