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 [actualizar], 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 .
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:
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 las 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 aún 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.
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 solo 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>
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]
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);( #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.,
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;|
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.+
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;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.
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:
Por ejemplo:
<! ATTLIST img src CDATA #REQUIRED ID ID #IMPLIED tipo CDATA #FIXED "verdadero" de impresión ( sí | no ) "sí" >
A continuación, se muestran algunos tipos de atributos compatibles con SGML y XML:
CDATA
ID
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
ID
en 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
ENTITY
o ENTITIES
(''value1''|...)
|
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''|...)
|
" 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.
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.
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 se pueden definir 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 predefinidas se sustituyen dondequiera que se produzcan, sin necesidad de un analizador de validación (solo se introducen mediante el carácter "&").
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 PUBLIC
o SYSTEM
de estas entidades externas especifica el FPI y / o el URI donde se encuentran los datos no analizados de la entidad externa, y el NDATA
pará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 ENTITY
tipo para el data
atributo ), 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:
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:
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.
Un ejemplo de una DTD XML externa muy simple para describir el esquema de una lista de personas podría consistir en:
<! ELEMENT lista_de_personas ( persona ) * > <! ELEMENTO persona ( nombre , fecha de nacimiento ?, Sexo ?, Número de seguridad social ?) > <! ELEMENTO nombre ( #PCDATA ) > <! ELEMENTO fecha de nacimiento ( #PCDATA ) > <! ELEMENTO sexo ( # PCDATA ) > <! ELEMENT número de seguridad social ( #PCDATA ) >
Tomando esta línea por línea:
people_list
es un nombre de elemento válido y una instancia de dicho elemento contiene cualquier número de person
elementos. El *
indica que puede haber 0 o más person
elementos dentro del people_list
elemento.person
es 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 name
nombre del elemento no tiene ?
, por lo que un person
elemento debe contener un name
elemento.name
es un nombre de elemento válido y una instancia de dicho elemento contiene "datos de caracteres analizados" (#PCDATA).birthdate
es un nombre de elemento válido y una instancia de dicho elemento contiene datos de caracteres analizados.gender
es un nombre de elemento válido y una instancia de dicho elemento contiene datos de caracteres analizados.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):
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.
Este artículo necesidades específicas adicionales o más categorías . ( Junio de 2020 ) |