Hispanopedia Wiki
Articulo de referencia

Definición del tipo de documento

Una definición de tipo de documento ( DTD ) es un archivo de especificación que contiene un conjunto de declaraciones de marcado que definen un tipo de documento para un lenguaj...

Hispanopedia WikiContenido en espanolLectura gratuita

Una definición de tipo de documento ( DTD ) es un archivo de especificación que contiene un conjunto de declaraciones de marcado que definen un tipo de documento para un lenguaje de marcado de la familia SGML ( GML , SGML , XML , HTML ). El archivo de especificación DTD se puede utilizar para validar documentos.

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 puede declararse directamente dentro de un documento XML o como una referencia externa. [ 1 ]

Las DTD persisten en aplicaciones que necesitan caracteres de publicación especiales, como las Referencias de Entidades de Caracteres XML y HTML , que derivan de conjuntos más amplios definidos como parte del esfuerzo de estandarización ISO SGML . XML utiliza un subconjunto de DTD SGML . Se estaba desarrollando un intento de crear DTD conscientes del espacio de nombres como la Parte 9 de ISO DSDL , pero finalmente se retiró. [ 2 ]

A partir de 2009Los lenguajes de esquema más recientes que tienen en cuenta los espacios de nombres XML (como W3C XML Schema e ISO RELAX NG ) han reemplazado en gran medida a los DTD como una mejor manera de validar la estructura XML.

Asociar DTD con documentos

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

Los DOCTYPE hacen dos tipos de declaraciones:

  • un subconjunto externo opcional
  • un subconjunto interno opcional .

Las declaraciones del subconjunto interno forman parte del DOCTYPE del documento. Las declaraciones del subconjunto externo se encuentran en un archivo de texto aparte . Se puede hacer referencia al subconjunto externo mediante un identificador público o un identificador de sistema . Es posible que los programas de lectura de documentos no necesiten leer 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 las declaradas dentro de su subconjunto interno ), solo puede ser analizado parcialmente, pero no puede ser validado completamente por analizadores SGML o XML de validación 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 siguen siendo totalmente analizables en el modo no independiente de los analizadores de validación, que señala un error si no puede localizar estas entidades externas con su identificador público (FPI) o identificador de sistema (una URI) especificado, o si 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 que utiliza el analizador SGML o XML). Los analizadores que no realizan validación pueden intentar localizar estas entidades externas en el modo no independiente (interpretando parcialmente la DTD solo para resolver sus entidades analizables declaradas), pero no validan el modelo de contenido de estos documentos.

Ejemplos

El siguiente ejemplo de DOCTYPE contiene identificadores tanto públicos como 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 una de las tres DTD de SGML. Los identificadores públicos de estas DTD son constantes y son los siguientes:

  • -//W3C//DTD HTML 4.01//EN
  • -//W3C//DTD HTML 4.01 Transitional//EN
  • -//W3C//DTD HTML 4.01 Frameset//EN

Los identificadores de sistema de estas DTD, si están presentes en el DOCTYPE, son referencias URI . Un identificador de sistema generalmente apunta a un conjunto específico de declaraciones en una ubicación resoluble. SGML permite asignar identificadores públicos a identificadores de sistema en catálogos que están disponibles opcionalmente para los resolvedores 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 los 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, simplemente 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 documentos ni para todos los documentos SGML, cuyos elementos de nivel superior pueden ser diferentes del elemento raíz implícito), e indica el nombre del 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

Las DTD describen la estructura de una clase de documentos mediante declaraciones de elementos y listas de atributos. Las declaraciones de elementos especifican el conjunto de elementos permitidos dentro del documento y si los elementos declarados y las secuencias de datos de caracteres pueden estar contenidos dentro de cada elemento, y de qué manera. Las declaraciones de listas de atributos especifican el conjunto de atributos permitidos para cada elemento declarado, incluyendo el tipo de cada valor de atributo, si no se proporciona 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 permitidas en la estructura de la clase correspondiente de documentos XML. [ 4 ]

Declaraciones de tipo de elemento

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

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

  • EMPTYpara especificar que el elemento definido no permite ningún contenido, es decir, no puede tener ningún elemento hijo, ni siquiera elementos de texto (si hay espacios en blanco, se ignoran);
  • ANYpara especificar que el elemento definido permite cualquier contenido, sin restricciones, es decir, que puede tener cualquier número (incluido ninguno) y tipo de elementos secundarios (incluidos elementos de texto);
  • o una expresión que especifique 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 pueden restringirse; esto puede ser:
      • (#PCDATA): históricamente significa datos de caracteres analizados , lo que implica que solo se permite un elemento de texto en el contenido (no se permite ningún cuantificador);
      • (#PCDATA|''elementname''|...)*: una selecció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 elementos de texto o los elementos con nombre especificados) se puede utilizar 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 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 con los nombres de los 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 secuencias o una lista de opciones . Puede ir seguida 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 y el orden relativo especificados;
        • 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 solo carácter que sigue inmediatamente al elemento especificado al que se aplica, para restringir el número de ocurrencias 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 elemento: 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 elemento 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:

<!ELEMENTO html ( head , body ) > <!ELEMENTO p ( #PCDATA | p | ul | dl | table | h1 | h2 | h3 )* >

Las declaraciones de tipo de elemento son ignoradas por los analizadores SGML y XML que no realizan validación (en cuyo caso, se aceptan todos los elementos en cualquier orden y en cualquier número de ocurrencias en el documento analizado), pero estas declaraciones aún se verifican en cuanto a su forma y validez.

Declaraciones de listas de atributos

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. [ 5 ]

Por ejemplo:

<!ATTLIST img src CDATA #REQUERIDO id ID #IMPLIADO sort CDATA #FIJO "verdadero" print ( sí | no ) "sí" >

A continuación se muestran algunos tipos de atributos compatibles tanto con SGML como con 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 el DTD pueden documentar con más detalle los valores que se aceptan efectivamente, pero la sintaxis del DTD no permite una especificación tan precisa);
ID
El valor efectivo del atributo debe ser un identificador válido, y se utiliza para definir y anclar al elemento actual el destino de las referencias que utilizan este identificador definido (incluidos los identificadores de fragmentos de documento que pueden especificarse al final de una URI después de un signo "#"); es un error si elementos distintos en el mismo documento definen el mismo identificador; la restricción de unicidad también implica que el identificador en sí no conlleva ninguna 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 parte de un documento XML.
IDREFoIDREFS
el valor efectivo del atributo solo puede ser un identificador válido (o una lista de identificadores separados por espacios) y debe hacer referencia al elemento único definido en el documento con un atributo declarado con el tipo IDen el DTD (o el elemento único definido en un documento XML con un pseudoatributo " xml:id") y cuyo valor efectivo es el mismo identificador;
NMTOKENoNMTOKENS
El valor efectivo del atributo solo puede ser un token de nombre válido (o una lista de tokens de nombre separados por espacios), pero no está restringido a un identificador único dentro del documento; este nombre puede tener una semántica suplementaria y dependiente de la aplicación y puede requerir restricciones de nomenclatura adicionales, pero esto está fuera del alcance de la DTD;
ENTITYoENTITIES
El valor efectivo del atributo solo puede ser el nombre de una entidad externa no analizada (o una lista de dichos nombres separados por espacios), que también debe declararse en la declaración del tipo de documento; este tipo no es compatible con los 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 (especificada entre paréntesis y separada por un |carácter de barra vertical " ") de valores textuales, donde cada valor de la enumeración puede especificarse entre comillas 'simples 'o "dobles "si no es un token de nombre simple;
NOTATION (notation1|...)
El valor efectivo del atributo solo puede ser uno de los |nombres de notación enumerados (especificados entre paréntesis y separados por el carácter de barra vertical " "), 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 los 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 omita en una etiqueta XML.

Las declaraciones de listas de atributos son ignoradas por los analizadores SGML y XML que no realizan validación (en cuyo caso se acepta cualquier atributo dentro de todos los elementos del documento analizado), pero estas declaraciones aún se verifican para comprobar su correcta formación y validez.

Declaraciones de entidades

Una entidad es similar a una macro . La declaración de la entidad le asigna un valor que se conserva a lo largo del documento. Un uso común es tener un nombre más reconocible que una referencia numérica para un carácter desconocido. [ 6 ] Las entidades ayudan a mejorar la legibilidad de un texto XML. En general, existen dos tipos: internas y externas.

  • 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 a una entidad con nombre en el resto del documento (incluido el resto de la DTD), y si este nombre de entidad se ha definido efectivamente como una entidad analizada, la referencia 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 caracteres con nombre predefinidas son similares a las entidades internas; sin embargo, cinco de ellas reciben un tratamiento especial en todos los analizadores de SGML, HTML y XML. Estas entidades difieren ligeramente de las entidades analizadas normalmente, ya que cuando se encuentra una referencia a una entidad de caracteres con nombre en el documento, la referencia se reemplaza inmediatamente por el contenido del carácter definido en la entidad. El análisis continúa después del texto de reemplazo, que se inserta literalmente en el token que se está analizando (si dicho carácter está permitido en el valor textual de ese token). Esto permite que algunos caracteres necesarios para la sintaxis básica de HTML o XML se liberen de su función sintáctica especial (en particular, "&", reservado para las referencias de entidades iniciales; "<" o "">", que delimitan las etiquetas de marcado; y las comillas dobles o simples, que delimitan los valores de los atributos y las definiciones de entidades). Las entidades de caracteres predefinidas también incluyen referencias numéricas de caracteres que se manejan de la misma manera y que también se pueden usar para liberar los caracteres que representan o para sortear las limitaciones del repertorio de caracteres admitido por la codificación del documento.
    • En los perfiles básicos para SGML o en documentos HTML, no es posible declarar entidades internas (porque no se recuperan los subconjuntos DTD externos y los subconjuntos DTD internos no son compatibles con estos perfiles básicos).
    • En cambio, los estándares HTML predefinen un amplio conjunto de varios cientos de entidades de caracteres con nombre, que aún pueden ser tratadas 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 mediante un nombre único en el documento y se definen con un identificador público (un FPI) y/o un identificador de sistema (interpretado como un URI ) que especifica la fuente de su contenido. De hecho, existen en dos variantes:
    • entidades externas analizadas (generalmente definidas con un identificador SYSTEM que indica la 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 estuviera declarado como entidades internas (la entidad externa contiene su texto de reemplazo efectivo);
    • Entidades externas no analizadas que están definidas y asociadas 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 quedan a cargo de la aplicación, según los tipos de anotaciones que admita (consulte la siguiente sección sobre anotaciones y ejemplos de entidades externas no analizadas).
    • Las entidades externas no son compatibles con los perfiles básicos de SGML ni con los documentos HTML, pero son válidas en las implementaciones completas de SGML y en XML 1.0 o 1.1 (incluidos XHTML y SVG, aunque no sean estrictamente necesarias en esos tipos de documentos).

Un ejemplo de declaraciones de entidades internas (en este caso, en un subconjunto DTD interno de un documento SGML) es:

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

Las entidades internas pueden definirse en cualquier orden, siempre que no se haga referencia a ellas ni se analicen 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 no definida dentro del contenido de una entidad analizada, pero no es válido incluir en ningún otro lugar ninguna referencia a una entidad con nombre antes de que esta entidad se haya definido completamente, incluidas todas las demás entidades internas a las que se haga referencia en su contenido definido (esto también evita definiciones circulares o recursivas de entidades internas). Este documento se analiza como si fuera:

<!DOCTYPE sgml [ <!ELEMENT sgml ANY > <!ENTITY % std "SGML estándar" > <!ENTITY % signature " — &author;." > <!ENTITY % question "¿Por qué no pude publicar mis libros directamente en SGML estándar?" > <!ENTITY % author "William Shakespeare" > ]>
¿ Por qué no pude publicar mis libros directamente en SGML estándar ? — William Shakespeare .

La referencia a la entidad interna "autor" no se sustituye en el texto de reemplazo de la entidad interna "firma". En cambio, se reemplaza solo cuando la referencia a la entidad "firma" se analiza dentro del contenido del elemento "sgml", pero solo por analizadores validadores (los analizadores no validadores no sustituyen las referencias a entidades que aparecen dentro del contenido del elemento o dentro de los valores de los atributos, en el cuerpo del documento.

Esto es posible porque el texto de reemplazo especificado en las definiciones internas de entidades permite distinguir entre referencias a entidades de parámetros (que se introducen con el carácter "%" y cuyo reemplazo se aplica al contenido del DTD analizado) y referencias a entidades generales (que se introducen con el carácter "&" y cuyo reemplazo se retrasa hasta que se analizan y validan correctamente). El carácter "%" para introducir referencias a entidades de parámetros en el DTD pierde su función especial fuera del DTD y se convierte en un carácter literal.

Sin embargo, las referencias a entidades de caracteres predefinidas se sustituyen dondequiera que aparezcan, sin necesidad de un analizador validador (solo se introducen mediante el carácter "&").

declaraciones de notación

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

<!NOTACIÓN tipo-imagen-svg SISTEMA "imagen/svg" >

Esto declara el tipo de medio de las 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 específica de la aplicación que genera o utiliza 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 los analizadores XML o SGML, o un URI del SISTEMA, 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 a un renderizador específico, o un URN que indique un identificador de objeto específico del sistema operativo, como un UUID).

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

Se pueden asociar notaciones a entidades externas no analizadas incluidas en el cuerpo del documento SGML o XML. El parámetro PUBLIC`or` 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, en este caso, el tipo MIME). Por ejemplo:

<!DOCTYPE sgml [ <!ELEMENT sgml ( img )* ><!ELEMENTO img VACÍO > <!LISTA DE ATRIBUTOS img datos ENTIDAD #IMPLIADO ><!ENTIDAD example1SVG SISTEMA "example1.svg" DATOS NDATA example1SVG-rdf > <!NOTACIÓN example1SVG-rdf SISTEMA "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 usarse como valor de un atributo de elemento (como arriba) o dentro del contenido del elemento, siempre que la DTD permita dichas entidades externas en el tipo de contenido declarado de los elementos o en el tipo declarado de los atributos (en este caso, el ENTITYtipo para el dataatributo), o que el analizador SGML no esté validando el contenido.

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

<!DOCTYPE sgml [ <!ELEMENT sgml ( img )* > <!--  el valor del atributo opcional "type" solo se puede establecer en esta notación.  --> <!ATTLIST sgml type NOTATION ( type-vendor-specific ) #IMPLIED ><!ELEMENT img ANY > <!-- El contenido opcional solo puede ser datos SGML o XML analizables --> <!--  El valor del atributo opcional "title" debe ser analizable como texto.  El valor del atributo opcional "data" se establece en una entidad externa no analizada.  El valor del atributo opcional "type" solo puede ser una de las dos notaciones.  --> <!ATTLIST img title CDATA #IMPLIED data ENTITY #IMPLIED type NOTATION ( type-image-svg | type-image-gif ) #IMPLIED ><!--  Las notaciones hacen referencia a entidades externas y pueden establecerse en los atributos "type" anteriores,  o deben ser referenciadas por cualquier entidad externa definida que no pueda ser analizada.  --> <!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 sin analizar --> ]>
<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 no analizada --> <img title= "&example1SVGTitle;" data= "example1SVG" /><!-- una imagen GIF no es analizable y solo se puede referenciar como una entidad externa --> <img title= "&example1GIFTitle;" data= "example1GIF" /> </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 (la URI estándar) de un documento SVG 1.1, en lugar de especificar solo un identificador del sistema como en el primer ejemplo (que era una URI relativa interpretada localmente como un tipo MIME). Esta anotación se referencia directamente dentro del atributo "type" no analizado 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 se utiliza directamente en un atributo "type" declarado, cuyo contenido se especifica en el DTD con el atributo "NOTATION" type (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 es analizada por analizadores validadores 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 es analizada por analizadores validadores y el texto de reemplazo de la entidad se localiza mediante su identificador SYSTEM definido "example1.svg" (que también se interpreta como una URI relativa). El contenido efectivo para el elemento "img" es 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 la DTD, mientras que la imagen GIF solo se referencia como un objeto externo opaco (que no se puede analizar con SGML) a través de su atributo "data" (cuyo tipo de valor es una ENTIDAD opaca).

Solo se puede especificar un nombre de notación en el valor de los atributos ENTITY (SGML, XML 1.0 y XML 1.1 no admiten múltiples nombres de notación en la misma ENTIDAD externa declarada, por lo que se necesitan atributos separados). Sin embargo, se pueden referenciar varias entidades externas (en una lista de nombres separados por espacios) en atributos declarados con el tipo ENTITIES, 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 puedan hacer referencia (para estos analizadores, solo tienen un nombre único asociado a un identificador público (un FPI) y/o un identificador de sistema (un URI)).

Algunas aplicaciones (pero no los analizadores XML o SGML en sí) también permiten referenciar notaciones indirectamente al nombrarlas en el "URN:''name''"valor de un atributo CDATA estándar, en cualquier lugar donde se pueda especificar una URI. Sin embargo, este comportamiento es específico de la aplicación y requiere que esta mantenga un catálogo de URN conocidos para resolverlos en las notaciones que han sido analizadas por un analizador SGML o XML estándar. Este uso permite que las notaciones se definan únicamente en una DTD almacenada como una entidad externa y se referencien solo como el subconjunto externo de documentos, y permite que estos documentos sigan siendo compatibles con analizadores XML o SGML que validan y que no tienen soporte directo para notaciones.

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

  • Todas las entidades externas utilizadas por estos tipos de documentos estándar se referencian mediante 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 un elemento de imagen "img", cuyos valores se interpretan como una URI, sin necesidad de ningún catálogo de identificadores públicos, es decir, FPI conocidos).
  • Todas las entidades externas para metadatos adicionales se referencian mediante:
    • Atributos adicionales (como type , que indica el tipo MIME de la entidad externa, o el atributo charset , que indica su codificación).
    • Elementos adicionales (como enlaces o metadatos en HTML y XHTML) dentro de sus propios atributos.
    • Pseudoatributos estándar en XML y XHTML (como xml:lang , o xmlns y xmlns:* para declaraciones de espacios de nombres).

Incluso al validar analizadores SGML, XML 1.0 o XML 1.1, las entidades externas a las que hace referencia un FPI o URI en las notaciones declaradas no son recuperadas automáticamente por los propios analizadores. En cambio, estos analizadores simplemente proporcionan a la aplicación el FPI o URI analizado asociado a las notaciones encontradas 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 validadores también comprueban la unicidad de las declaraciones de nombres de notación e informan de un error de validación si algunos nombres de notación se utilizan en cualquier parte del DTD o en el cuerpo del documento pero no están declarados.

  • Si la aplicación no puede utilizar 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 señalar un error.
  • De lo contrario, las aplicaciones deciden por sí mismas cómo interpretarlas, y luego si las entidades externas deben recuperarse y analizarse por separado.
  • Las aplicaciones pueden entonces indicar un error si dicha interpretación, recuperación o análisis independiente falla.
  • Las anotaciones no reconocidas que puedan provocar que una aplicación señale un error no deben impedir la interpretación del documento validado que las utiliza.

DTD XML y validación de esquemas

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

La mayoría de los lenguajes de esquema XML solo reemplazan las declaraciones de elementos y las declaraciones de listas de atributos, de manera que es posible analizar documentos XML con analizadores XML que no validan (si el único propósito del subconjunto DTD externo fuera 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 independiente no es realmente posible con estos lenguajes: la declaración del tipo de documento sigue siendo necesaria al menos para identificar (con un catálogo XML ) el esquema utilizado en el documento XML analizado y que se valida en otro lenguaje.

Existe la idea errónea de que un analizador XML que no valida no tiene que leer las declaraciones de tipo de documento, cuando en realidad, las declaraciones de tipo de documento deben seguir siendo analizadas para comprobar la sintaxis correcta, así como la validez de las declaraciones, y el analizador debe seguir analizando todas las declaraciones de entidades en el subconjunto interno y sustituir los textos de reemplazo de las entidades internas que aparezcan en cualquier parte de la declaración de tipo de documento o en el cuerpo del documento.

Sin embargo, un analizador sintáctico que no valida puede optar por no leer entidades externas analizables (incluido el subconjunto externo ) y no tiene que respetar las restricciones del modelo de contenido definidas en las declaraciones de elementos y en las declaraciones de listas 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 indicarlo standalone="no"en su declaración XML . El DTD de validación puede identificarse utilizando catálogos XML para recuperar su subconjunto externo especificado .

En el ejemplo siguiente, 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 algún identificador SYSTEM para el subconjunto externo, no se puede procesar de forma segura como independiente: se debe recuperar el URI, de lo contrario, puede haber entidades de caracteres con nombre desconocidas cuya definición podría ser necesaria para analizar correctamente la sintaxis XML efectiva en el subconjunto interno o en el cuerpo del documento (el análisis de la sintaxis XML normalmente se realiza después de la sustitución de todas las entidades con nombre, 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 algún identificador PUBLIC, se puede procesar como independiente, si el procesador XML conoce este identificador PUBLIC en su catálogo local desde donde puede recuperar una entidad DTD asociada.

Ejemplo de esquema XML DTD

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 ( person )* > <!ELEMENT person ( name , birthdate ?, gender ?, socialsecuritynumber ?) > <!ELEMENT name ( #PCDATA ) > <!ELEMENT birthdate ( #PCDATA ) > <!ELEMENT gender ( #PCDATA ) > <!ELEMENT socialsecuritynumber ( #PCDATA ) >

Analizando esto 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 *símbolo 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 llamado name, seguido de uno llamado 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. namees un nombre de elemento válido, y una instancia de dicho elemento contiene "datos de caracteres analizados" (#PCDATA).
  4. birthdatees un nombre de elemento válido, y una instancia de dicho elemento contiene datos de caracteres analizados.
  5. genderes un nombre de elemento válido, y una instancia de dicho elemento contiene datos de caracteres analizados.
  6. socialsecuritynumberes 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 cumple con esta DTD. La DTD se referencia aquí como un subconjunto externo, a través del especificador SYSTEM y una URI. Se supone que podemos identificar la DTD con la referencia URI relativa "example.dtd"; "people_list" después de "!DOCTYPE" nos indica que las etiquetas raíz, o el primer elemento definido en la DTD, se denominan "people_list".

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

Esto se puede visualizar en un navegador compatible con 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 otro 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 cumpla con las reglas del DTD; solo se les exige que verifiquen que el DTD sea sintácticamente correcto. Por motivos de seguridad, también pueden optar por no leer el DTD externo.

La misma DTD también puede incrustarse directamente en el propio documento XML como un subconjunto interno, encerrándola entre corchetes en la declaración del tipo de documento, en cuyo caso el documento ya no depende de entidades externas y puede procesarse en modo independiente:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <!DOCTYPE people_list [  <!ELEMENT people_list (person*)> <!ELEMENT person (name, birthdate?, gender?, socialsecuritynumber?)> <!ELEMENT name (#PCDATA)> <!ELEMENT birthdate (#PCDATA)> <!ELEMENT gender (#PCDATA)> <!ELEMENT socialsecuritynumber (#PCDATA)> ]> <people_list> <person> <name> Fred Bloggs </name> <birthdate> 2008-11-27 </birthdate> <gender> Masculino </gender> </person> </people_list>

Alternativas

Existen alternativas a las DTD (para especificar esquemas):

  • XML Schema , también conocido como XML Schema Definition (XSD), ha alcanzado el estatus de Recomendación dentro del W3C, [ 9 ] y es popular para el uso de XML "orientado a datos" (es decir, transaccional no editorial) debido a su tipado más fuerte y la facilidad de conversión a declaraciones Java. La mayor parte del mundo editorial ha descubierto que la complejidad adicional de XSD no les aportaría ningún beneficio particular, por lo que las DTD siguen siendo mucho más populares en ese ámbito. Una XML Schema Definition 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. [ 10 ] Es más expresivo que XSD, a la vez que proporciona una sintaxis más simple, pero el soporte de software comercial ha tardado en llegar.

Seguridad

Un DTD XML puede utilizarse para crear un ataque de denegación de servicio definiendo entidades anidadas que se expanden exponencialmente, o enviando el analizador XML a un recurso externo que nunca devuelve respuesta. [ 11 ]

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

Véase también

Referencias

  1. ↑ "Introducción a DTD" .
  2. ↑ "ISO/IEC 19757-9:2008 (Retirado) – Parte 9: Declaración de espacio de nombres y tipo de datos en las definiciones de tipo de documento (DTD)" . ISO . Consultado el 30 de marzo de 2026 .
  3. ↑ "doctypedecl" . Lenguaje de marcado extensible (XML) 1.1 . W3C.
  4. ↑ Watt, Andrew H. (2002). Sams aprende XML en 10 minutos . Sams Publishing. ISBN 9780672324710.
  5. ↑ Declaración de lista de atributos , Especificaciones del lenguaje de marcado extensible (XML) 1.1, W3C.
  6. ↑ "Entidades DTD" . Tutorial de DTD . W3Schools.
  7. ↑ Declaraciones de notación , Especificaciones del lenguaje de marcado extensible (XML) 1.0, W3C.
  8. ↑ Declaraciones de notación , Especificaciones del lenguaje de marcado extensible (XML) 1.1, W3C.
  9. ↑ "Esquema XML Parte 1: Estructuras (Segunda edición)" . W3C. 2004. Consultado el 2 de enero de 2022 .
  10. ↑ "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 .
  11. 1 2 Bryan Sullivan (noviembre de 2009). "Ataques y defensas de denegación de servicio XML" . Revista MSDN . Recuperado el 21 de octubre de 2013 .
  • Definición de la declaración de tipo de documento XML del Lenguaje de Marcado Extensible (XML) 1.0 (Cuarta Edición) en W3.org