Definición de tipo de documento
Conjunto de declaraciones de marcado que definen un tipo de documento para un lenguaje de marcado de la familia SGML

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 se puede declarar en línea dentro de un documento XML o como una referencia externa. [1]

Se está desarrollando una versión de DTD que tenga en cuenta los espacios 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 derivan de conjuntos más grandes definidos como parte del esfuerzo del estándar ISO SGML . XML utiliza un subconjunto de DTD SGML .

A partir de 2009 [actualizar], los lenguajes de esquema más nuevos que reconocen 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.

Asociación de DTD con documentos

Un 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 el DTD al que se hace referencia.

Los DOCTYPE realizan dos tipos de declaraciones:

  • un subconjunto externo opcional
  • un subconjunto interno opcional .

Las declaraciones del subconjunto interno forman parte del DOCTYPE en el documento mismo. Las declaraciones del subconjunto externo se encuentran en un archivo de texto independiente. Se puede hacer referencia al subconjunto externo mediante un identificador público o un identificador del sistema . Es posible que no sea necesario que los programas de lectura de 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 puede analizarse parcialmente, pero no puede validarse completamente mediante 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, estos documentos todavía se pueden analizar completamente en el modo no autónomo de los analizadores de validación, lo que indica un error si no puede localizar estas entidades externas con su identificador público (FPI) o identificador del sistema (URI) especificado, o si son inaccesibles. (Las anotaciones declaradas en el 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 autónomo 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 no validadores pueden intentar eventualmente localizar estas entidades externas en el modo no autónomo (interpretando parcialmente el DTD solo para resolver sus entidades analizables declaradas), pero no validan el modelo de contenido de estos documentos.

Ejemplos

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

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

Todos los documentos HTML 4.01 cumplen con 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 estos 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 solucionadores 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, sólo 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 fragmentos de documentos o 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 nombran el conjunto de elementos permitidos dentro del documento y especifican si los elementos declarados y las series de datos de caracteres pueden estar contenidos dentro de cada elemento y de qué manera. Las declaraciones de listas de atributos nombran el conjunto de atributos permitidos para cada elemento declarado, incluido el tipo de cada valor de atributo, si no es 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. [3]

Declaraciones de tipos de elementos

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.

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

  • EMPTYpara especificar que el elemento definido no permite 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 restricción, es decir, que puede tener cualquier número (incluso ninguno) y tipo de elementos secundarios (incluidos elementos de texto);
  • o una expresión que especifica 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 nombrados, pero no se puede restringir su orden ni el número de apariciones; esto puede ser:
      • ( #PCDATA ):históricamente significa datos de caracteres analizados , lo que significa que solo se permite un elemento de texto en el contenido (no se permite ningún cuantificador);
      • ( #PCDATA | ''element name'' | ... )*:se puede utilizar una selección limitada (en una lista exclusiva entre paréntesis y separada por |caracteres de barra vertical " " y terminada con el *cuantificador " " requerido) de dos o más elementos secundarios (incluidos solo elementos de texto o los elementos nombrados especificados) en cualquier orden y número de ocurrencias en el contenido.
    • un elemento content , 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). Este tipo de 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 de 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 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 especificada y en el 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 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 ningún 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 )* >

Las declaraciones de tipo de elemento son ignoradas por los analizadores SGML y XML no validadores (en cuyos casos, 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 determinado, la lista de todos los atributos posibles asociados a 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  #OBLIGATORIO  id  ID  #IMPLÍCITO  sort  CDATA  #FIXED  "true"  print  ( yes  |  no )  "yes" >

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 además los valores que se aceptan efectivamente, pero la sintaxis de la 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 objetivo 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 lleva ninguna otra semántica y que los identificadores deben tratarse como opacos en las aplicaciones; XML también predefine el pseudoatributo estándar " " xml:idcon 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 sólo 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 el DTD (o el elemento único definido en un documento XML con un pseudoatributo " xml:id") y cuyo valor efectivo sea el mismo identificador;
NMTOKENoNMTOKENS
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 tener semántica complementaria y dependiente de la aplicación y puede requerir restricciones de nombres adicionales, pero esto está fuera del alcance de la DTD;
ENTITYoENTITIES
el valor efectivo del atributo sólo puede ser el nombre de una entidad externa no analizada (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 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 en la enumeración posiblemente se especifica 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 (especificada entre paréntesis y separada 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 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 no validadores (en cuyo caso se acepta cualquier atributo dentro de todos los elementos del documento analizado), pero estas declaraciones aún se verifican para verificar su correcta formación y validez.

Declaraciones de entidades

Una entidad es similar a una macro . La declaración de 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 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: 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 del DTD declarado en el documento). Cuando se encuentra una referencia a una entidad nombrada en el resto del documento (incluido el resto del DTD), y si este nombre de entidad se ha definido efectivamente como una entidad analizada, la referencia misma 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: 5 de ellas, sin embargo, se tratan de manera especial 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 caracteres con nombre en el documento, la referencia también se reemplaza inmediatamente por el contenido del carácter definido en la entidad, pero el análisis continúa después del texto de reemplazo, que se inserta inmediatamente de manera literal en el token analizado actualmente (si dicho carácter está permitido en el valor textual de ese token). Esto permite que algunos caracteres que son necesarios para la sintaxis central de HTML o XML se escapen de su función sintáctica especial (en particular, "&", que se reserva 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 entidad). Las entidades de caracteres predefinidas también incluyen referencias de caracteres numéricos que se manejan de la misma manera y también pueden usarse para escapar los caracteres que representan o para eludir limitaciones en el repertorio de caracteres admitido por la codificación del documento.
    • En los perfiles básicos para SGML o en documentos HTML, no es posible la declaración de entidades internas (porque no se recuperan subconjuntos DTD externos y los subconjuntos DTD internos no se admiten en 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 el DTD utilizado por el analizador.
  • Las entidades externas hacen referencia a objetos de almacenamiento externo. Se declaran simplemente con 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 de dónde proviene su contenido. Existen, de hecho, en dos variantes:
    • entidades externas analizadas (generalmente definidas con un identificador SYSTEM 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 validadores recuperan sus contenidos y los analizan como si estuvieran declarados como entidades internas (la entidad externa que contiene su texto de reemplazo efectivo);
    • entidades externas no analizadas 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, de acuerdo con los tipos de anotaciones que admite (consulte la siguiente sección sobre anotaciones y ejemplos de entidades externas no analizadas).
    • Las entidades externas no se admiten en 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 (incluidos XHTML y SVG, incluso si no son estrictamente necesarias en esos tipos de documentos).

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

<!DOCTYPE  sgml  [  <!ELEMENT  sgml  ANY >  <!ENTITY  %  std  "standard SGML" >  <!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 una referencia a una entidad nombrada antes de que esta entidad haya sido completamente definida, 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  "SGML estándar" >  <!ENTITY  %  signature  " — &author;." >  <!ENTITY  %  question  "¿Por qué no puedo publicar mis libros directamente en SGML estándar?" >  <!ENTITY  %  author  "William Shakespeare" > ]>
<sgml> ¿Por qué  no pude  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 cambio, se reemplaza solo cuando la referencia a la entidad "firma" se analiza dentro del contenido del elemento "sgml", pero solo mediante analizadores de validación (los analizadores no de validación 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 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 generales (que se introducen con el carácter "&" y cuyo reemplazo se retrasa hasta que se analizan y validan de manera efectiva). El carácter "%" para introducir referencias de entidad de parámetro 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 (sólo 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 se deja en manos de la aplicación (que las interpreta directamente o recupera la entidad externa por sí misma), 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 y asociarlas con un renderizador específico:

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

Esto declara el TEXTO 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 que es 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 una FPI PÚBLICA, registrada en los catálogos utilizados por los analizadores XML o SGML, o una URI del SISTEMA, cuya interpretación depende de la aplicación (aquí un tipo MIME, interpretado como una URI relativa, pero podría ser una URI absoluta para un renderizador específico, o una URN que indica 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. [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  VACÍO >  <!ATTLIST  img  datos  ENTIDAD  #IMPLIED > <!ENTIDAD  ejemplo1SVG  SISTEMA  "ejemplo1.svg"  NDATA  ejemplo1SVG-rdf >  <!NOTACIÓN  ejemplo1SVG-rdf  SISTEMA  "ejemplo1.svg.rdf" > ]>
<sgml> <img data= "ejemplo1SVG" /> </sgml>

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

Las notaciones también pueden asociarse directamente a los 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 "type" opcional 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 "title" opcional debe poder analizarse como texto.  El valor del atributo "data" opcional se establece en una entidad externa no analizada.  El valor del atributo "type" opcional 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 configurarse en los atributos "type" anteriores,  o deben ser referenciadas por cualquier entidad externa definida que no pueda analizarse.  -->  <!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 no analizada --> <img title= "&example1SVGTitle;" data= "example1SVG" />     <!-- una imagen GIF no se puede analizar y solo se puede referenciar como una entidad externa --> <img title= "&example1GIFTitle;" data= "example1GIF" /> </sgml>

El ejemplo anterior muestra una notación denominada "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 era un URI relativo interpretado localmente como un tipo MIME). Se hace referencia a esta anotación directamente dentro del atributo "type" no analizado del elemento "img", pero no se recupera su contenido. 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 nombrada se utiliza directamente en un atributo "type" declarado, cuyo contenido se especifica en el DTD con el tipo de atributo "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 es analizada por analizadores de validación y el texto de reemplazo de 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 de validación y el texto de reemplazo de la entidad se encuentra por su identificador SYSTEM definido "example1.svg" (también interpretado como un URI relativo). 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 el DTD, donde 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 (no existe soporte en SGML, XML 1.0 o XML 1.1 para múltiples nombres de notación en la misma ENTIDAD 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 referenciar (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) también permiten hacer referencias 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 se haga referencia a él solo como el subconjunto externo de documentos, y permite que estos documentos sigan siendo compatibles con los analizadores XML o SGML de validación 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 son 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 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 el tipo , que indica el tipo MIME de la entidad externa, o el atributo charset , que indica su codificación)
    • Elementos adicionales (como enlaces o meta 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 en la validación de analizadores SGML o XML 1.0 o XML 1.1, las entidades externas a las que hace referencia un FPI y/o URI en notaciones declaradas no son recuperadas automáticamente por los propios analizadores. En su lugar, estos analizadores simplemente proporcionan a la aplicación el FPI y/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 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 del DTD o en el cuerpo del documento pero no se declaran:

  • Si la aplicación no puede utilizar ninguna notación (o si su FPI y/o URI son desconocidos o no están soportados en su catálogo local), la aplicación puede ignorar estas notaciones silenciosamente o puede señalar un error.
  • De lo contrario, las aplicaciones deciden por sí mismas cómo interpretarlas y, en ese caso, si las entidades externas deben recuperarse y analizarse por separado.
  • Las aplicaciones pueden entonces señalar un error si dicha interpretación, recuperación o análisis separado falla.
  • Las anotaciones no reconocidas que pueden hacer que una aplicación señale un error no deben bloquear la interpretación del documento validado que las utiliza.

DTD XML y validación de esquemas

La sintaxis DTD de XML es una de las muchas que existen en los lenguajes de esquemas XML . Sin embargo, muchos de ellos no reemplazan por completo a la DTD de XML. En particular, la DTD de 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 esquemas XML y porque otras entidades y notaciones externas no analizables no tienen asignaciones equivalentes simples en la mayoría de los lenguajes de esquemas XML).

La mayoría de los lenguajes de esquema XML son solo reemplazos para declaraciones de elementos y declaraciones de listas de atributos, de tal manera que se hace posible analizar documentos XML con analizadores XML no validadores (si el único propósito del subconjunto DTD externo era 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 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 se valida en otro lenguaje.

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

Sin embargo, un analizador no validador 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 las entidades externas analizables declaradas en el subconjunto interno ), debe afirmarlo standalone="no"en su declaración XML. El DTD de validación se puede identificar 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 "ejemplo.dtd"> <people_list />

Si la declaración de tipo de documento XML incluye cualquier 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 puede 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 cualquier 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 DTD XML

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  persona  ( nombre ,  fecha de nacimiento ?,  género ?,  número de seguro social ?) > <!ELEMENT  nombre  ( #PCDATA ) > <!ELEMENT  fecha de nacimiento  ( #PCDATA ) > <!ELEMENT  género  ( #PCDATA ) > <!ELEMENT  número de seguro social  ( #PCDATA ) >

Tomando esto línea por línea:

  1. people_listes un nombre de elemento válido y una instancia de dicho elemento contiene cualquier cantidad de personelementos. Esto *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 este DTD. Aquí se hace referencia al DTD como un subconjunto externo, a través del especificador SYSTEM y un URI. Se supone que podemos identificar el DTD con la referencia URI relativa "example.dtd"; el "people_list" después de "!DOCTYPE" nos indica que las etiquetas raíz, o el primer elemento definido en el DTD, se llama "people_list":

<?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE people_list SYSTEM "example.dtd"> <people_list> <persona> <nombre> Fred Bloggs </nombre> <fecha de nacimiento> 2008-11-27 </fecha de nacimiento> <género> Masculino </género> </persona> </people_list>

Se puede representar esto 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 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 cumpla las reglas del DTD; solo se les exige que comprueben que el DTD sea sintácticamente correcto. Por razones de seguridad, también pueden optar por no leer el DTD externo.

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 lista_personas [  <!ELEMENT lista_personas (persona*)> <!ELEMENT persona (nombre, fecha de nacimiento?, género?, número_seguro_social?)> <!ELEMENT nombre (#PCDATA)> <!ELEMENT fecha de nacimiento (#PCDATA)> <!ELEMENT género (#PCDATA)> <!ELEMENT número_seguro_social (#PCDATA)>     ]><people_list> <person> <name> Fred Bloggs </name> <birthdate> 2008-11-27 </birthdate> <gender> Masculino </gender> </person> </people_list>

Alternativas

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

  • El esquema XML , también conocido como definición de esquema XML (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, transaccional no editorial) debido a su tipado más fuerte y su ida y vuelta más fácil a las declaraciones Java. [ cita requerida ] La mayor parte del mundo editorial ha descubierto que la complejidad añadida de XSD no les traería ningún beneficio particular, [ cita requerida ] por lo que las DTD siguen siendo 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 ] al mismo tiempo que proporciona una sintaxis más simple, [ cita requerida ] pero el soporte del software comercial ha tardado en llegar.

Seguridad

Se puede utilizar un DTD XML 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 este motivo, .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 superiores) se niegan a abrir archivos XML que contienen declaraciones DTD.

Véase también

Referencias

  1. ^ "Introducción a DTD".
  2. ^ "doctypedecl". Lenguaje de marcado extensible (XML) 1.1 . W3C.
  3. ^ Watt, Andrew H. (2002). Sams: aprenda a usar XML en 10 minutos. Sams Publishing. ISBN 9780672324710.
  4. ^ Declaración de lista de atributos, Especificaciones del lenguaje de marcado extensible (XML) 1.1, W3C.
  5. ^ "Entidades DTD". Tutorial de DTD . W3Schools.
  6. ^ Declaraciones de notación, Especificaciones del lenguaje de marcado extensible (XML) 1.0, W3C.
  7. ^ Declaraciones de notación, Especificaciones del lenguaje de marcado extensible (XML) 1.1, W3C.
  8. ^ "Esquema XML Parte 1: Estructuras (segunda edición)". W3C. 2004. Consultado el 2 de enero de 2022 .
  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. ^ de Bryan Sullivan (noviembre de 2009). "Ataques y defensas de denegación de servicio XML". Revista MSDN . Consultado el 21 de octubre de 2013 .
  • Definición de la declaración del tipo de documento XML de Extensible Markup Language (XML) 1.0 (cuarta edición) en W3.org
Obtenido de "https://es.wikipedia.org/w/index.php?title=Definición_de_tipo_de_documento&oldid=1212673118"