Definición del tipo de documento
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 la familia SGML (GML, SGML, XML, HTML).
Una DTD define los componentes básicos 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.
XML usa un subconjunto de SGML DTD.
A partir de 2009, los lenguajes de esquema compatibles con el espacio de nombres XML más nuevos (como W3C XML Schema e ISO RELAX NG) han reemplazado en gran medida a las DTD. Se está desarrollando una versión de DTD con reconocimiento de espacio de nombres como Parte 9 de ISO DSDL. Los DTD persisten en aplicaciones que necesitan caracteres de publicación especiales, como las referencias de entidad de caracteres XML y HTML, que se derivan de conjuntos más grandes definidos como parte del esfuerzo estándar ISO SGML.
Asociación de DTD con documentos
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 inicio de un documento XML. La declaración establece que el documento es una instancia del tipo definido por la DTD referenciada.
DOCTYPEs hacen dos tipos de declaraciones:
- una opción subconjunto externo
- una opción subconjunto interno.
Las declaraciones en el subconjunto interno forman parte del DOCTYPE en el documento mismo. Las declaraciones en el subconjunto externo se encuentran en un archivo de texto separado. Se puede hacer referencia al subconjunto externo a través de un identificador público y/o un identificador de sistema. Es posible que no se requieran programas para leer documentos para 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 se puede analizar parcialmente, pero no se puede validar por completo mediante validación de analizadores SGML o XML en su modo independiente (esto significa que estos analizadores de validación no intentan recuperar estas entidades externas y no se puede acceder a su texto de reemplazo).
Sin embargo, dichos documentos todavía se pueden analizar por completo en el modo no independiente de los analizadores de validación, lo que indica un error si no puede ubicar estas entidades externas con su identificador público especificado (FPI) o identificador del sistema (un URI), 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 mediante el analizador SGML o XML). Los analizadores que no validan pueden eventualmente intentar ubicar estas entidades externas en el modo no independiente (al interpretar parcialmente el DTD solo para resolver sus entidades analizables declaradas), pero no validar el modelo de contenido de estos documentos.
Ejemplos
El siguiente ejemplo de un DOCTYPE contiene identificadores públicos y de sistema:
¡Atención! DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transición/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 estos 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 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 resoluble. SGML permite asignar 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:
¿Según la versión xml="1.0" encoding="utf-8"?¡Seguido! DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional///EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"El cuerpo de documentos XHTML comienza aquí...html xmlns="http://www.w3.org/1999/xhtml"■...
Identificado/html
También se puede proporcionar un subconjunto interno adicional después del subconjunto externo:
¿Según la versión xml="1.0" encoding="utf-8"?¡Seguido! DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional///EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" [ Un subconjunto interno puede incrustarse aquí...]
El cuerpo de documentos XHTML comienza aquí...html xmlns="http://www.w3.org/1999/xhtml"■...
Identificado/html
Alternativamente, solo se puede proporcionar el subconjunto interno:
¿Según la versión xml="1.0" encoding="utf-8"?¡Atención! DOCTYPE html Un subconjunto interno puede incrustarse aquí...]
El cuerpo de documentos XHTML comienza aquí...html xmlns="http://www.w3.org/1999/xhtml"■...
Identificado/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 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 de tipo del elemento raíz:
¿Según la versión xml="1.0" encoding="utf-8"?¡Atención! DOCTYPE htmlEl cuerpo de documentos XHTML comienza aquí...html xmlns="http://www.w3.org/1999/xhtml"■...
Identificado/html
Declaraciones de marcado
Los DTD describen la estructura de una clase de documentos a través de declaraciones de elementos y listas de atributos. Las declaraciones de elementos nombran el conjunto permitido de elementos dentro del documento y especifican si y cómo los elementos declarados y las series de datos de caracteres pueden estar contenidos dentro de cada elemento. 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 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 se permiten en la estructura de la clase correspondiente de documentos XML.
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 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 permite ningún contenido, es decir, no puede tener elementos infantiles, ni siquiera elementos de texto (si hay espacios blancos, se ignoran);ANY
para especificar que el elemento definido permite cualquier contenido, sin restricción, es decir, que pueda tener cualquier número (incluido ninguno) y tipo de elementos infantiles (incluidos los elementos de texto);- o expresión, especificando los únicos elementos permitidos como niños directos en el contenido del elemento definido; este contenido puede ser:
- a contenido mixto, lo que significa que el contenido puede incluir al menos un elemento de texto y elementos cero o más nombrados, pero su orden y número de ocurrencias no pueden ser restringidos; esto puede ser:
( #PCDATA )
: históricamente significado datos de caracteres pares, esto significa que sólo se permite un elemento de texto en el contenido (no se permite ningún cuantificador);( #PCDATA | ''element name'' | ... )*
: una elección limitada (en una lista exclusiva entre paréntesis y separada por "|
"Características de tubería y terminada por el requerido"*
"cuantificador) de dos o más elementos infantiles (incluidos sólo elementos de texto o los elementos mencionados) pueden utilizarse en cualquier orden y número de ocurrencias en el contenido.
- an elemento contenido, lo que significa que no debe haber elementos de texto en los niños elementos del contenido (todos los espacios blancos codificados entre los elementos del niño son ignorados, al igual que los comentarios). Dicho contenido de elementos se especifica como partículas en una variante de la forma Backus-Naur sin símbolos terminales y nombres de elementos como símbolos no-terminal. El contenido de Element consiste en:
- a partículas puede ser el nombre de un elemento declarado en el DTD, o lista de secuencias o lista de selección. Puede ser seguido por un opcional quantifier.
- a lista de secuencias significa una lista ordenada (se especifica entre paréntesis y separada por un "
,
"coma carácter) de uno o más partículas de contenido: todo el partículas de contenido debe aparecer sucesivamente como niños directos en el contenido del elemento definido, en la posición especificada y el orden relativo; - a lista de selección significa una lista mutuamente excluyente (especificada entre paréntesis y separada por un "
|
" carácter de tuberías" de dos o más partículas de contenido: sólo uno de estos partículas de contenido puede aparecer en el contenido del elemento definido en la misma posición.
- a lista de secuencias significa una lista ordenada (se especifica entre paréntesis y separada por un "
- A quantifier es un carácter único que inmediatamente sigue el artículo especificado que aplica, para restringir el número de sucesivas ocurrencias de estos artículos en la posición especificada en el contenido del elemento; puede ser:
+
para especificar que debe haber una o más ocurrencias del artículo, el contenido efectivo de cada ocurrencia puede ser diferente;*
para especificar que se permite cualquier número (cero o más) de ocurrencias; el artículo es opcional y el contenido efectivo de cada ocurrencia puede ser diferente;?
para especificar que no debe haber más de una ocurrencia, el objeto es opcional;- Si no hay cuantificador, el artículo especificado debe ocurrir exactamente una vez en la posición especificada en el contenido del elemento.
- a partículas puede ser el nombre de un elemento declarado en el DTD, o lista de secuencias o lista de selección. Puede ser seguido por un opcional quantifier.
- a contenido mixto, lo que significa que el contenido puede incluir al menos un elemento de texto y elementos cero o más nombrados, pero su orden y número de ocurrencias no pueden ser restringidos; esto puede ser:
Por ejemplo:
¡Atención! html ()cabeza, cuerpo)■¡Atención! p ()#PCDATA Silencio p Silencio ul Silencio ♪ Silencio cuadro Silencio h1Silencioh2Silencioh3)*■
Las declaraciones de tipo de elemento son ignoradas por los analizadores SGML y XML sin validación (en cuyo caso, cualquier elemento se acepta en cualquier orden y en cualquier número de ocurrencias en el documento analizado), pero estos todavía se verifica la forma y la validez de las declaraciones.
Declaraciones de lista 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.
Por ejemplo:
¡Atención! ATTLIST img src CDATA #REQUIRED id ID #IMPLIED especie CDATA #FIXED "verdad" impresión ()Sí. Silencio no) Sí.■
Estos son algunos tipos de atributos admitidos tanto por SGML como por XML:
CDATA
- este tipo significa 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 más valores que sean efectivamente aceptados, pero la sintaxis DTD no permite tal especificación 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 referencias utilizando este identificador definido (incluidos como identificadores fragmentos de documento que pueden ser especificados al final de un URI después de un signo "#"); es un error si elementos distintos en el mismo documento están definiendo el mismo identificador; la limitación de la singularidad implica también que el seudético no lleva ningún otro semán
xml:id
"con este tipo, sin necesidad de ninguna declaración en el DTD, por lo que la limitación de singularidad también se aplica a estos identificadores definidos cuando se especifican en cualquier lugar de un documento XML. IDREF
oIDREFS
- el valor efectivo del atributo sólo puede ser un identificador válido (o una lista separada del espacio de tales identificadores) y debe estar haciendo referencia al elemento único definido en el documento con un atributo declarado con el tipo
ID
en el 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
oNMTOKENS
- el valor efectivo del atributo sólo puede ser un nombre válido token (o una lista separada de tales fichas de nombre), pero no se limita a un identificador único dentro del documento; este nombre puede llevar semántica suplementaria y dependiente de la aplicación y puede requerir restricciones adicionales de nominación, pero esto está fuera del alcance del DTD;
ENTITY
oENTITIES
- el valor efectivo del atributo sólo puede ser el nombre de una entidad externa sin par (o una lista separada del espacio de tales nombres), que también debe ser declarado en la declaración del tipo de documento; este tipo no es compatible con parsers HTML, pero es válido en SGML y XML 1.0 o 1.1 (incluyendo XHTML y SVG);
(''value1''|...)
- el valor efectivo del atributo sólo puede ser una de las listas enumeradas (se especifica entre paréntesis y separado por un "
|
"caracter) de los valores textuales, donde cada valor en la enumeración se especifica posiblemente entre'
single'
o"
doble"
comillas si no es un simple nombre token; NOTATION (''notation1''|...)
- el valor efectivo del atributo sólo puede ser cualquiera de la lista enumerada (se especifica entre paréntesis y separado por un "
|
"Característica de tubo) de nombres de notación, donde cada nombre de notación en la enumeración debe ser declarado también en la declaración del tipo de documento; este tipo no es compatible con parásers HTML, pero es válido en SGML y XML 1.0 o 1.1 (incluyendo XHTML y SVG).
Un valor predeterminado puede definir si debe aparecer un atributo (# REQUERIDO
) 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 lista de atributos son ignoradas por los analizadores SGML y XML sin 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 ver si están bien formadas. y validez.
Declaraciones de entidades
Una entidad es similar a una macro. La declaración de entidad le asigna un valor que se mantiene 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. Las entidades ayudan a mejorar la legibilidad de un texto XML. En general, hay dos tipos: internos y externos.
- Entidades internas (paradas) están asociando 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 una referencia de entidad nombrada se encuentra entonces en el resto del documento (incluido en el resto del DTD), y si este nombre de entidad se ha definido efectivamente como una entidad analizada, la referencia en sí misma se sustituye inmediatamente por el contenido textual definido en la entidad analizada, y el perfeccionamiento continúa dentro de este texto de sustitución.
- Entidades de carácter predefinidas son similares a las entidades internas: 5 de ellos, sin embargo, se tratan especialmente en todos los analizadores SGML, HTML y XML. Estas entidades son un poco diferentes de las entidades normalizadas, ya que cuando una referencia de entidad de carácter nombrada se encuentra en el documento, la referencia también es reemplazada inmediatamente por el contenido de caracteres definido en la entidad, pero el análisis continúa después el texto de sustitución, que se inserta inmediatamente literalmente en el token actualmente analizado (si tal carácter está permitido en el valor textual de esa 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 (notablemente "cliente" que está reservada para las referencias de la entidad inicial, "traducido" o "conejérte" que delimitan las etiquetas de marcado, y "doble" o "single" comillas, que delimitan los valores de atributos y definiciones de entidad). Las entidades de carácter predefinidas también incluyen referencias de carácter numérico que se manejan de la misma manera y también se pueden utilizar para escapar de los caracteres que representan, o para evitar limitaciones en el repertorio de caracteres apoyado por la codificación del documento.
- En perfiles básicos para SGML o en documentos HTML, la declaración de entidades internas no es posible (porque los subconjuntos DTD externos no se recuperan, y los subconjuntos DTD internos no son compatibles en estos perfiles básicos).
- En su lugar, los estándares HTML predefinen un gran conjunto de varios cientos de entidades de carácter nombradas, que todavía pueden ser manejadas como entidades de pares estándar definidas en el DTD utilizado por el analizador.
- Entidades externas se refieren a objetos de almacenamiento externos. Acaban de ser declarados por un nombre único en el documento, y definidos con un identificador público (un FPI) y/o un identificador del sistema (interpretado como un URI) especificando donde la fuente de su contenido. Existen de hecho en dos variantes:
- entidades externas (más a menudo definido con un identificador SYSTEM indicando la URI de su contenido) que son no asociado en su definición a una anotación nombrada, en cuyo caso validar los analizadores XML o SGML recuperar su contenido y considerarlos como entidades internas (la entidad externa que contiene su texto de reemplazo eficaz);
- entidades externas no comprendidas que se definen y se 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 utilizando el parser SGML o XML: su interpretación, recuperación y pares se deja a la aplicación, de acuerdo con los tipos de anotaciones que soporta (vea la sección siguiente sobre anotaciones y para ejemplos de entidades externas sin par).
- Las entidades externas no son compatibles con perfiles básicos para SGML o en documentos HTML, pero son válidas en implementaciones completas de SGML y en XML 1.0 o 1.1 (incluyendo XHTML y SVG, incluso si no son estrictamente necesarias en esos tipos de documentos).
Un ejemplo de declaraciones de entidades internas (aquí en un subconjunto DTD interno de un documento SGML) es:
¡Atención! DOCTYPE sgml [ ¡Atención! sgml CUALQUIER■ ¡Cierto! % std "SGML estándar"■ ¡Cierto! % firma "#x2014; "autor;".■ ¡Cierto! % cuestión "¿Por qué iba a publicar mis libros directamente en %std?"■ ¡Cierto! % autor "William Shakespeare"■]
IdentificadoCuestiones;■/sgml
Las entidades internas se pueden definir en cualquier orden, siempre que 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 no definida dentro del contenido de una entidad analizada, pero no es válido incluir en ningún otro lugar ninguna referencia de entidad nombrada antes de que esta entidad se haya definido por completo, incluidas todas las demás entidades internas a las que se hace referencia en su contenido definido (esto también evita definiciones circulares o recursivas de entidades internas). Este documento se analiza como si fuera:
¡Atención! DOCTYPE sgml [ ¡Atención! sgml CUALQUIER■ ¡Cierto! % std "SGML estándar"■ ¡Cierto! % firma " — " autor ".■ ¡Cierto! % cuestión "¿Por qué no podía publicar mis libros directamente en SGML estándar?"■ ¡Cierto! % autor "William Shakespeare"■]
Identificado¿Por qué no podía publicar mis libros directamente en SGML estándar? - William Shakespeare.■/sgml
Referencia al "autor" entidad interna no se sustituye en el texto de reemplazo de la "firma" entidad interna. En cambio, se reemplaza solo cuando la "firma" la referencia de la entidad se analiza dentro del contenido del "sgml" elemento, pero solo mediante analizadores de validación (los analizadores que no validan no sustituyen las referencias a entidades que ocurren 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 entidades internas permite una distinción entre referencias de entidades de parámetro (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 mediante el carácter "&" y cuya sustitución se retrasa hasta que se analizan y validan efectivamente). El "%" 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 ocurran, sin necesidad de un analizador de validación (solo se introducen con 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 a la aplicación (que las interpreta directamente o recupera la entidad externa), asignándoles un nombre simple, que se puede utilizar 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 para asociarlas con un renderizador específico:
¡Atención! NOTA tipo-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 las notaciones suelen seguir 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 XML o analizadores SGML, o un URI DEL SISTEMA, cuya interpretación depende de la aplicación (aquí, 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 declarada 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 la conformidad con XML.
Las notaciones se pueden asociar a entidades externas no analizadas incluidas en el cuerpo del documento SGML o XML. El 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
de estas entidades definidas especifica la notación adicional (es decir, efectivamente el tipo MIME aquí). Por ejemplo:
¡Atención! DOCTYPE sgml [ ¡Atención! sgml ()img)*■ ¡Atención! img EMPTY■ ¡Atención! ATTLIST img datos ENTIDAD #IMPLIED■ ¡Cierto! ejemplo1SVG SYSTEM "example1.svg" NDATA ejemplo1SVG-rdf■ ¡Atención! NOTA ejemplo1SVG-rdf SYSTEM "example1.svg.rdf"■]
Identificado ■img data="example1SVG" /■/sgml
Dentro del cuerpo del documento SGML, estas entidades externas referenciadas (cuyo nombre se especifica entre "&" y ";") no reemplazadas como entidades con nombre habituales (definidas con un valor CDATA), pero 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 la DTD permita tal entidades externas en el tipo de contenido declarado de elementos o en el tipo declarado de atributos (aquí el ENTIDAD
tipo para el data
atributo), o el analizador SGML no está validando el contenido.
Las notaciones también se pueden asociar 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 la DTD dentro del <!ATTLIST ...>
declaración del elemento). Por ejemplo:
¡Atención! DOCTYPE sgml [ ¡Atención! sgml ()img)*■ ¡Seguido! el valor de atributo opcional "tipo" sólo se puede establecer a esta notación. -- ¡Atención! ATTLIST sgml Tipo NOTA () tipo-vendor específico ) #IMPLIED■ ¡Atención! img CUALQUIER■ - contenido opcional puede ser sólo datos SGML o XML perceptibles ¡Seguido! El valor de atributo "título" opcional debe ser parsable como texto. El valor de atributo "datos" opcional se establece en una entidad externa sin par. El valor de atributo "tipo" opcional sólo puede ser una de las dos notaciones. -- ¡Atención! ATTLIST img Título CDATA #IMPLIED datos ENTIDAD #IMPLIED Tipo NOTA () tipo-image-svg Silencio tipo-image-gif ) #IMPLIED■ ¡Seguido! Las notaciones están haciendo referencia a entidades externas y pueden establecerse en los atributos "tipo" anteriores, o debe ser referenciado por cualquier entidad externa definida que no pueda ser analizada. -- ¡Atención! NOTA tipo-image-svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"■ ¡Atención! NOTA tipo-image-gif PUBLIC "image/gif"■ ¡Atención! NOTA tipo-vendor específico PUBLIC "application/VND.specific+sgml"■ ¡Cierto! ejemplo1SVGTitle "Título del ejemplo1.svg"■ - entidad interna pareada - ¡Cierto! ejemplo1SVG SYSTEM "example1.svg"■ - entidad externa pareada... ¡Cierto! ejemplo1GIFTitle "Título del ejemplo1.gif"■ - entidad interna pareada - ¡Cierto! ejemplo1GIF SYSTEM "example1.gif" NDATA tipo-image-gif■ - entidad externa sin par...]
. Tipo="tipo-vendor específico"■ Una imagen SVG puede ser parsable como texto SGML o XML válidos ■img Título="Título" Tipo="tipo-image-svg"■&le1SVG;■/imgió - Se puede hacer referencia también como una entidad externa sin par - ■img Título="Título" data="example1SVG" / ¡Sea!-- una imagen GIF no es perceptible y sólo puede ser referenciada como una entidad externa -- ■img Título="Conexample1GIFTitle" 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 "tipo" atributo de la "img" elemento, pero su contenido no se recupera. También declara otra notación para una aplicación específica del proveedor, para anotar el "sgml" elemento raíz en el documento. En ambos casos, la notación declarada named se usa directamente en un "tipo" atributo, cuyo contenido se especifica en la DTD con la "NOTACIÓN" tipo de atributo (este atributo "tipo" se declara para el elemento "sgml", así como para el elemento "img").
Sin embargo, el "título" atributo de la "img" especifica la entidad interna "example1SVGTTitle" cuya declaración no define una anotación, por lo que se analiza mediante la validación de analizadores y el texto de reemplazo de la entidad es "Título de ejemplo1.svg".
El contenido de la "img" elemento 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 encuentra por su identificador de SISTEMA definido "example1.svg" (también interpretado como un URI relativo). El contenido efectivo para el "img" elemento sea 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, 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 & #34;datos" atributo (cuyo tipo de valor es una ENTIDAD opaca).
Solo se puede especificar un nombre de notación en el valor de los atributos de ENTIDAD (no hay 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 pueden hacer referencia a varias entidades externas (en una lista de nombres separados por espacios) en atributos declarados con el tipo ENTIDADES, 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 de 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 todas partes se puede 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 convertirlos 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 una DTD almacenada como una entidad externa y referenciada 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 las notaciones.
Las notaciones no se utilizan en HTML ni en perfiles básicos para XHTML y SVG porque:
- Todas las entidades externas utilizadas por estos tipos de documentos estándar se refieren a atributos simples, declarados con el tipo CDATA en su DTD estándar (como el atributo "href" de un elemento ancla "a", o el atributo "src" de un elemento de imagen "img", cuyos valores se interpretan como un URI, sin necesidad de ningún catálogo de identificadores públicos, es decir, conocido FPI)
- Todas las entidades externas para meta-datos adicionales se refieren a:
- Atributos adicionales (como Tipo, que indica el tipo MIME de la entidad externa, o charset atributo, que indica su codificación)
- Elementos adicionales (como enlace o meta en HTML y XHTML) dentro de sus propios atributos
- Seudo-atributos estándar en XML y XHTML (como xml:lang, o xmlns y xmlns:* para declaraciones de espacio de nombres).
Incluso al validar analizadores SGML, 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 simplemente proporcionan a la aplicación el FPI y/o el URI analizados asociados 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 la 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 usan en cualquier parte de la 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 compatibles en su catálogo local), estas notaciones pueden ser ignoradas silenciosamente por la aplicación o la aplicación podría indicar un error.
- De lo contrario, las aplicaciones deciden cómo interpretarlas, entonces si las entidades externas deben ser recuperadas y luego ser analizadas por separado.
- Las aplicaciones pueden entonces indicar un error, si tal interpretación, recuperación o pares separados falla.
- Las notaciones no reconocidas que pueden causar que una aplicación señale un error no deben bloquear la interpretación del documento validado utilizando ellos.
DTD XML y validación de esquemas
La sintaxis XML DTD es uno de varios lenguajes de esquema XML. Sin embargo, muchos de los lenguajes de esquema no reemplazan por completo el 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 solo reemplazos para declaraciones de elementos y declaraciones de listas de atributos, de tal manera que es 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 autónomo puro 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 está validado en otro idioma.
Un concepto erróneo 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 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.
Un analizador no validador puede, sin embargo, optar por no leer entidades externas analizables (incluido el subconjunto externo), y no tienen 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 afirmar standalone="no"
en su declaración XML. La DTD de validación puede identificarse mediante el uso de 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:
¿No?¡Seguido! DOCTYPE people_list SYSTEM "example.dtd"Identificar gente_list /
Si la declaración de tipo de documento XML incluye cualquier identificador de SISTEMA 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 desconocido cuya definición se necesite para analizar correctamente la sintaxis XML efectiva en el subconjunto interno o en el cuerpo del documento (el análisis de sintaxis XML normalmente se realiza después de la sustitución de todas las entidades nombradas, excluyendo las cinco entidades que están predefinidas en XML y que son sustituido implícitamente después de analizar el documento XML en tokens léxicos). Si solo incluye cualquier identificador PÚBLICO, puede procesarse como independiente, si el procesador XML conoce este identificador PÚBLICO en su catálogo local desde donde puede recuperar una entidad DTD asociada.
Ejemplo de esquema XML DTD
Un ejemplo de una DTD XML externa muy simple para describir el esquema de una lista de personas podría consistir en:
¡Atención! people_list ()persona)*■¡Atención! persona ()Nombre, Fecha de nacimiento? género? socialsecuritynumber?■¡Atención! Nombre ()#PCDATA)■¡Atención! Fecha de nacimiento ()#PCDATA)■¡Atención! género ()#PCDATA)■¡Atención! socialsecuritynumber ()#PCDATA)■
Tomando esto línea por línea:
people_list
es un nombre de elemento válido, y una instancia de tal elemento contiene cualquier número deperson
elementos. El*
puede haber 0 o másperson
elementos dentropeople_list
elemento.person
es un nombre de elemento válido, y una instancia de tal elemento contiene un elemento llamadoname
, seguido de uno llamadobirthdate
(opcional), entoncesgender
(también opcional) ysocialsecuritynumber
(también opcional). El?
indica que un elemento es opcional. La referencia a laname
nombre del elemento no?
Así que...person
elemento Debe contiene unname
elemento.name
es un nombre de elemento válido, y una instancia de tal elemento contiene "datos de caracteres separados" (#PCDATA).birthdate
es un nombre de elemento válido, y una instancia de tal elemento contiene datos de caracteres paresed.gender
es un nombre de elemento válido, y una instancia de tal elemento contiene datos de caracteres paresed.socialsecuritynumber
es un nombre de elemento válido, y una instancia de tal elemento contiene datos de caracteres paresed.
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. Supone que podemos identificar la DTD con la referencia URI relativa "example.dtd"; la "lista_de_personas" después de "!DOCTYPE" nos dice que las etiquetas raíz, o el primer elemento definido en la DTD, se llama "lista_de_personas":
¿No?¡Seguido! DOCTYPE people_list SYSTEM "example.dtd"* People_list ■persona NombreFred BloggsIdentificado/nombre ■birthdate2008-11-27■/birthdate IdentificadorHombre■/gender título ■/persona■/personas_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 otro nombre y abriendo el archivo XML con el navegador. Los archivos deben guardarse en el mismo directorio. Sin embargo, muchos navegadores no verifican que un documento XML cumpla con las reglas de la DTD; solo están obligados a comprobar que la DTD es sintácticamente correcta. Por motivos 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 autónomo:
¿Según la versión xml="1.0" encoding="UTF-8" standalone="yes"?¡Atención! DOCTYPE people_list [ (persona*) (nombre, fecha de nacimiento?, género?, socialsecuritynumber?) Nombre (#PCDATA) (#PCDATA) (#PCDATA) Número de seguridad social (#PCDATA)]
* People_list ■persona NombreFred BloggsIdentificado/nombre ■birthdate2008-11-27■/birthdate IdentificadorHombre■/gender título ■/persona■/personas_list
Existen alternativas a las DTD (para especificar esquemas):
- XML Schema, también conocido como Definición de esquema XML (XSD), ha logrado el estado de recomendación dentro del W3C, y es popular para el uso XML "data orientada" (es decir, no publicar transaccional) debido a su mayor mecanizado y más fácil redondeo a las declaraciones de Java. La mayoría del mundo editorial ha encontrado que la complejidad agregada de XSD no les traería ningún beneficio particular, por lo que los DTD todavía son mucho más populares allí. Una definición de esquema XML es en sí mismo un documento XML, mientras que un DTD no lo es.
- RELAX NG, que es también parte de DSDL, es un estándar internacional ISO. Es más expresivo que XSD, al tiempo que proporciona una sintaxis más simple, pero el soporte de software comercial ha sido lento en venir.
Seguridad
Se puede usar una DTD XML para crear un ataque de denegación de servicio (DoS) al definir entidades anidadas que se expanden exponencialmente o al enviar el analizador XML a un recurso externo que nunca regresa.
Por este motivo,.NET Framework proporciona una propiedad que permite prohibir u omitir el análisis de DTD, y las versiones recientes de las aplicaciones de Microsoft Office (Microsoft Office 2010 y posteriores) se niegan a abrir archivos XML que contienen declaraciones de DTD.
Contenido relacionado
Codificación Manchester diferencial
Protocolo de transmisión en tiempo real (RTSP)
Ancho de banda (procesamiento de señal)