Definição do tipo de documento - Document type definition

Uma definição de tipo de documento ( DTD ) é um conjunto de declarações de marcação que definem um tipo de documento para uma linguagem de marcação de família SGML ( GML , SGML , XML , HTML ).

Um DTD define os blocos de construção válidos de um documento XML. Ele define a estrutura do documento com uma lista de elementos e atributos validados. Um DTD pode ser declarado embutido em um documento XML ou como uma referência externa.

XML usa um subconjunto de SGML DTD.

A partir de 2009, as linguagens de esquema reconhecidas por namespace XML mais recentes (como W3C XML Schema e ISO RELAX NG ) substituíram amplamente os DTDs. Uma versão de DTDs com reconhecimento de namespace está sendo desenvolvida como a Parte 9 da ISO DSDL . Os DTDs persistem em aplicativos que precisam de caracteres especiais de publicação, como XML e HTML Character Entity References , que derivam de conjuntos maiores definidos como parte do esforço padrão ISO SGML .

Associando DTDs a documentos

Um DTD é associado a um documento XML ou SGML por meio de uma declaração de tipo de documento (DOCTYPE). O DOCTYPE aparece no fragmento sintático doctypedecl próximo ao início de um documento XML. A declaração estabelece que o documento é uma instância do tipo definido pelo DTD referenciado.

DOCTYPEs fazem dois tipos de declaração:

  • um subconjunto externo opcional
  • um subconjunto interno opcional .

As declarações no subconjunto interno fazem parte do DOCTYPE no próprio documento. As declarações no subconjunto externo estão localizadas em um arquivo de texto separado. O subconjunto externo pode ser referenciado por meio de um identificador público e / ou um identificador de sistema . Os programas de leitura de documentos podem não ser necessários para ler o subconjunto externo.

Qualquer documento SGML ou XML válido que faça referência a um subconjunto externo em seu DTD, ou cujo corpo contenha referências a entidades externas analisadas declaradas em seu DTD (incluindo aquelas declaradas em seu subconjunto interno ), pode ser apenas parcialmente analisado, mas não pode ser totalmente validado por validação Analisadores SGML ou XML em seu modo autônomo (isso significa que esses analisadores de validação não tentam recuperar essas entidades externas e seu texto de substituição não está acessível).

No entanto, esses documentos ainda são totalmente analisáveis ​​no modo não autônomo de analisadores de validação, o que sinaliza um erro se não puder localizar essas entidades externas com seu identificador público (FPI) ou identificador de sistema (um URI) especificado , ou se estiverem inacessíveis . (As notações declaradas no DTD também fazem referência a entidades externas, mas essas entidades não analisadas não são necessárias para a validação de documentos no modo autônomo desses analisadores: a validação de todas as entidades externas referenciadas por notações é deixada para o aplicativo usando o SGML ou Analisador XML). Os analisadores não validadores podem eventualmente tentar localizar essas entidades externas no modo não- standalone (interpretando parcialmente o DTD apenas para resolver suas entidades analisáveis ​​declaradas), mas não validam o modelo de conteúdo desses documentos.

Exemplos

O exemplo a seguir de um DOCTYPE contém identificadores públicos e do sistema:

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

Todos os documentos HTML 4.01 estão em conformidade com um dos três DTDs SGML. Os identificadores públicos desses DTDs são constantes e são os seguintes:

Os identificadores de sistema desses DTDs, se presentes no DOCTYPE, são referências de URI . Um identificador de sistema geralmente aponta para um conjunto específico de declarações em um local resolvível. SGML permite mapear identificadores públicos para identificadores de sistema em catálogos que estão opcionalmente disponíveis para os resolvedores de URI usados ​​pelo software de análise de documentos .

Este DOCTYPE só pode aparecer após a declaração XML opcional e antes do corpo do documento, se a sintaxe do documento estiver em conformidade com o XML. Isso inclui 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">
<!-- the XHTML document body starts here-->
<html xmlns="http://www.w3.org/1999/xhtml">
 ...
</html>

Um subconjunto interno adicional também pode ser fornecido após o 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" [
  <!-- an internal subset can be embedded here -->
]>
<!-- the XHTML document body starts here-->
<html xmlns="http://www.w3.org/1999/xhtml">
 ...
</html>

Alternativamente, apenas o subconjunto interno pode ser fornecido:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html [
  <!-- an internal subset can be embedded here -->
]>
<!-- the XHTML document body starts here-->
<html xmlns="http://www.w3.org/1999/xhtml">
 ...
</html>

Finalmente, a definição do tipo de documento pode não incluir nenhum subconjunto; nesse caso, ele apenas especifica que o documento tem um único elemento de nível superior (este é um requisito implícito para todos os documentos XML e HTML válidos, mas não para fragmentos de documentos ou para todos os documentos SGML, cujos elementos de nível superior podem ser diferentes do elemento raiz implícito) e indica o nome do tipo do elemento raiz:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html>
<!-- the XHTML document body starts here-->
<html xmlns="http://www.w3.org/1999/xhtml">
 ...
</html>

Declarações de marcação

Os DTDs descrevem a estrutura de uma classe de documentos por meio de declarações de lista de elementos e atributos. As declarações de elemento nomeiam o conjunto permitido de elementos dentro do documento e especificam se e como os elementos declarados e execuções de dados de caractere podem estar contidos em cada elemento. As declarações de lista de atributos nomeiam o conjunto permitido de atributos para cada elemento declarado, incluindo o tipo de cada valor de atributo, se não um conjunto explícito de valores válidos.

As declarações de marcação DTD declaram quais tipos de elementos , listas de atributos , entidades e notações são permitidos na estrutura da classe correspondente de documentos XML.

Declarações de tipo de elemento

Uma declaração de tipo de elemento define um elemento e seu possível conteúdo. Um documento XML válido contém apenas elementos definidos no DTD.

Várias palavras-chave e caracteres especificam o conteúdo de um elemento:

  • EMPTY para especificar que o elemento definido não permite conteúdo, ou seja, não pode ter elementos filhos, nem mesmo elementos de texto (se houver espaços em branco, eles serão ignorados);
  • ANY para especificar que o elemento definido permite qualquer conteúdo, sem restrição, ou seja, que pode ter qualquer número (incluindo nenhum) e tipo de elementos filhos (incluindo elementos de texto);
  • ou uma expressão, especificando os únicos elementos permitidos como filhos diretos no conteúdo do elemento definido; este conteúdo pode ser:
    • um conteúdo misto , o que significa que o conteúdo pode incluir pelo menos um elemento de texto e zero ou mais elementos nomeados, mas sua ordem e número de ocorrências não podem ser restringidos; isso pode ser:
      • ( #PCDATA ): historicamente significando dados de caracteres analisados , isso significa que apenas um elemento de texto é permitido no conteúdo (nenhum quantificador é permitido);
      • ( #PCDATA | ''element name'' | ... )*: uma escolha limitada (em uma lista exclusiva entre parênteses e separada por " |" barras verticais e terminada pelo *quantificador " " obrigatório ) de dois ou mais elementos filho (incluindo apenas elementos de texto ou os elementos nomeados especificados) pode ser usada em qualquer ordem e número de ocorrências no conteúdo.
    • um conteúdo de elemento , o que significa que não deve haver nenhum elemento de texto nos elementos filhos do conteúdo (todos os espaços em branco codificados entre os elementos filhos são então ignorados, assim como os comentários). Tal conteúdo de elemento é especificado como partícula de conteúdo em uma variante da forma Backus – Naur sem símbolos terminais e nomes de elementos como símbolos não terminais. O conteúdo do elemento consiste em:
      • uma partícula de conteúdo pode ser o nome de um elemento declarado no DTD ou uma lista de sequência ou lista de escolha . Ele pode ser seguido por um quantificador opcional .
        • uma lista de sequência significa uma lista ordenada (especificada entre parênteses e separada por um ,caractere de vírgula " ") de uma ou mais partículas de conteúdo : todas as partículas de conteúdo devem aparecer sucessivamente como filhos diretos no conteúdo do elemento definido, na posição especificada e ordem relativa;
        • uma lista de escolha significa uma lista mutuamente exclusiva (especificada entre parênteses e separada por uma |barra vertical " ") de duas ou mais partículas de conteúdo : apenas uma dessas partículas de conteúdo pode aparecer no conteúdo do elemento definido na mesma posição.
      • Um quantificador é um único caractere que segue imediatamente o item especificado ao qual se aplica, para restringir o número de ocorrências sucessivas desses itens na posição especificada no conteúdo do elemento; pode ser:
        • + para especificar que deve haver uma ou mais ocorrências do item - o conteúdo efetivo de cada ocorrência pode ser diferente;
        • * para especificar que qualquer número (zero ou mais) de ocorrências é permitido - o item é opcional e o conteúdo efetivo de cada ocorrência pode ser diferente;
        • ? para especificar que não deve haver mais de uma ocorrência - o item é opcional;
        • Se não houver quantificador, o item especificado deve ocorrer exatamente uma vez na posição especificada no conteúdo do elemento.

Por exemplo:

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

As declarações de tipo de elemento são ignoradas por analisadores SGML e XML não-validadores (nos casos em que quaisquer elementos são aceitos em qualquer ordem e em qualquer número de ocorrências no documento analisado), mas essas declarações ainda são verificadas quanto à forma e validade.

Declarações de lista de atributos

Uma lista de atributos especifica para um determinado tipo de elemento a lista de todos os atributos possíveis associados a esse tipo. Para cada atributo possível, ele contém:

  • o nome declarado do atributo,
  • seu tipo de dados (ou uma enumeração de seus valores possíveis),
  • e seu valor padrão.

Por exemplo:

<!ATTLIST img
   src    CDATA          #REQUIRED
   id     ID             #IMPLIED
   sort   CDATA          #FIXED "true"
   print  (yes | no) "yes"
>

Aqui estão alguns tipos de atributos suportados por SGML e XML:

CDATA
este tipo significa dados de caracteres e indica que o valor efetivo do atributo pode ser qualquer valor textual, a menos que o atributo seja especificado como fixo (os comentários no DTD podem documentar valores que são efetivamente aceitos, mas a sintaxe do DTD não permite tal especificação precisa);
ID
o valor efetivo do atributo deve ser um identificador válido e é usado para definir e ancorar ao elemento atual o destino de referências usando este identificador definido (incluindo como identificadores de fragmento de documento que podem ser especificados no final de um URI após um " #" assinar); é um erro se elementos distintos no mesmo documento estão definindo o mesmo identificador; a restrição de exclusividade também implica que o próprio identificador não carrega nenhuma outra semântica e que os identificadores devem ser tratados como opacos nos aplicativos; XML também predefine o pseudo-atributo padrão " xml:id" com este tipo, sem a necessidade de qualquer declaração no DTD, portanto, a restrição de exclusividade também se aplica a esses identificadores definidos quando são especificados em qualquer lugar em um documento XML.
IDREF ou IDREFS
o valor efetivo do atributo só pode ser um identificador válido (ou uma lista separada por espaços de tais identificadores) e deve estar referenciando o elemento único definido no documento com um atributo declarado com o tipo IDno DTD (ou o elemento único definido em um documento XML com um pseudo-atributo " xml:id") e cujo valor efetivo é o mesmo identificador;
NMTOKEN ou NMTOKENS
o valor efetivo do atributo pode ser apenas um token de nome válido (ou uma lista separada por espaços de tais tokens de nome), mas não está restrito a um identificador exclusivo dentro do documento; esse nome pode conter semânticas complementares e dependentes do aplicativo e pode exigir restrições de nomenclatura adicionais, mas isso está fora do escopo do DTD;
ENTITY ou ENTITIES
o valor efetivo do atributo só pode ser o nome de uma entidade externa não analisada (ou uma lista separada por espaços de tais nomes), que também deve ser declarada na declaração de tipo de documento; este tipo não é suportado em analisadores HTML, mas é válido em SGML e XML 1.0 ou 1.1 (incluindo XHTML e SVG);
(''value1''|...)
o valor efetivo do atributo só pode ser um da lista enumerada (especificada entre parênteses e separada por uma |barra vertical " ") de valores textuais, onde cada valor na enumeração é possivelmente especificado entre aspas 'simples 'ou "duplas "se não for um token de nome simples;
NOTATION (''notation1''|...)
o valor efetivo do atributo só pode ser qualquer um da lista enumerada (especificada entre parênteses e separada por uma |barra vertical " ") de nomes de notação, onde cada nome de notação na enumeração também deve ser declarado na declaração de tipo de documento; este tipo não é suportado em analisadores HTML, mas é válido em SGML e XML 1.0 ou 1.1 (incluindo XHTML e SVG).

Um valor padrão pode definir se um atributo deve ocorrer ( #REQUIRED) ou não ( #IMPLIED), ou se ele tem um valor fixo ( #FIXED), ou qual valor deve ser usado como um valor padrão ("...") no caso de o atributo fornecido ser omitido em uma tag XML.

As declarações da lista de atributos são ignoradas por analisadores SGML e XML não-validadores (nos casos em que qualquer atributo é aceito em todos os elementos do documento analisado), mas essas declarações ainda são verificadas quanto à sua boa formação e validade.

Declarações de entidades

Uma entidade é semelhante a uma macro . A declaração da entidade atribui a ela um valor que é retido em todo o documento. Um uso comum é ter um nome mais reconhecível do que uma referência de caractere numérico para um caractere desconhecido. As entidades ajudam a melhorar a legibilidade de um texto XML. Em geral, existem dois tipos: interno e externo.

  • Entidades internas (analisadas) associam um nome a qualquer conteúdo textual arbitrário definido em sua declaração (que pode estar no subconjunto interno ou no subconjunto externo da DTD declarada no documento). Quando uma referência de entidade nomeada é encontrada no resto do documento (incluindo no resto do DTD), e se esse nome de entidade foi efetivamente definido como uma entidade analisada, a própria referência é substituída imediatamente pelo conteúdo textual definido em a entidade analisada e a análise continua dentro deste texto de substituição.
    • As entidades de caracteres nomeados predefinidas são semelhantes às entidades internas: 5 delas, no entanto, são tratadas especialmente em todos os analisadores SGML, HTML e XML. Essas entidades são um pouco diferentes das entidades normais analisadas, porque quando uma referência de entidade de caractere nomeada é encontrada no documento, a referência também é substituída imediatamente pelo conteúdo de caractere definido na entidade, mas a análise continua após o texto de substituição, que é imediatamente inserido literalmente no token atualmente analisado (se tal caractere for permitido no valor textual desse token). Isso permite que alguns caracteres necessários para a sintaxe principal do HTML ou XML escapem de sua função sintática especial (notavelmente "&", que é reservado para referências de entidades iniciais, "<" ou ">" que delimitam as tags de marcação, e aspas "duplas" ou 'simples', que delimitam os valores dos atributos e definições de entidade). As entidades de caracteres predefinidas também incluem referências de caracteres numéricos que são tratadas da mesma maneira e também podem ser usadas para escapar os caracteres que representam ou para contornar as limitações no repertório de caracteres com suporte pela codificação do documento.
    • Em perfis básicos para SGML ou em documentos HTML, a declaração de entidades internas não é possível (porque subconjuntos DTD externos não são recuperados e subconjuntos DTD internos não são suportados nesses perfis básicos).
    • Em vez disso, os padrões HTML predefinem um grande conjunto de várias centenas de entidades de caracteres nomeados, que ainda podem ser tratadas como entidades analisadas padrão definidas no DTD usado pelo analisador.
  • Entidades externas referem-se a objetos de armazenamento externos. Eles são apenas declarados por um nome único no documento e definidos com um identificador público (um FPI) e / ou um identificador de sistema (interpretado como um URI ) especificando onde está a origem de seu conteúdo. Eles existem de fato em duas variantes:
    • entidades externas analisadas (na maioria das vezes definidas com um identificador SYSTEM indicando o URI de seu conteúdo) que não estão associadas em sua definição a uma anotação nomeada, caso em que os analisadores de validação XML ou SGML recuperam seus conteúdos e os analisam como se fossem declarados como entidades internas (a entidade externa que contém seu texto de substituição efetivo);
    • entidades externas não analisadas que são definidas e associadas a um nome de anotação, caso em que são tratadas como referências opacas e sinalizadas como tal para o aplicativo usando o analisador SGML ou XML: sua interpretação, recuperação e análise são deixadas para o aplicativo, de acordo com os tipos de anotações que ele suporta (consulte a próxima seção sobre anotações e para exemplos de entidades externas não analisadas).
    • Entidades externas não são suportadas em perfis básicos para SGML ou em documentos HTML, mas são válidas em implementações completas de SGML e em XML 1.0 ou 1.1 (incluindo XHTML e SVG, mesmo que não sejam estritamente necessários nesses tipos de documentos).

Um exemplo de declarações de entidades internas (aqui em um subconjunto DTD interno de um documento SGML) é:

<!DOCTYPE sgml [
  <!ELEMENT sgml ANY>
  <!ENTITY % std       "standard SGML">
  <!ENTITY % signature " &#x2014; &author;.">
  <!ENTITY % question  "Why couldn&#x2019;t I publish my books directly in %std;?">
  <!ENTITY % author    "William Shakespeare">
]>
<sgml>&question;&signature;</sgml>

As entidades internas podem ser definidas em qualquer ordem, desde que não sejam referenciadas e analisadas na DTD ou no corpo do documento, em sua ordem de análise: é válido incluir uma referência a uma entidade ainda indefinida dentro do conteúdo de uma entidade analisada, mas é inválido incluir em qualquer outro lugar qualquer referência de entidade nomeada antes que esta entidade tenha sido totalmente definida, incluindo todas as outras entidades internas referenciadas em seu conteúdo definido (isso também evita definições circulares ou recursivas de entidades internas). Este documento é analisado como se fosse:

<!DOCTYPE sgml [
  <!ELEMENT sgml ANY>
  <!ENTITY % std       "standard SGML">
  <!ENTITY % signature " — &author;.">
  <!ENTITY % question  "Why couldn’t I publish my books directly in standard SGML?">
  <!ENTITY % author    "William Shakespeare">
]>
<sgml>Why couldn’t I publish my books directly in standard SGML? — William Shakespeare.</sgml>

A referência à entidade interna "autor" não é substituída no texto de substituição da entidade interna "assinatura". Em vez disso, ele é substituído apenas quando a referência de entidade de "assinatura" é analisada dentro do conteúdo do elemento "sgml", mas apenas por analisadores de validação (analisadores de não validação não substituem referências de entidade que ocorrem no conteúdo do elemento ou nos valores de atributo, no corpo do documento.

Isso é possível porque o texto de substituição especificado nas definições de entidade interna permite uma distinção entre referências de entidade de parâmetro (que são introduzidas pelo caractere "%" e cuja substituição se aplica ao conteúdo DTD analisado) e referências de entidade geral (que são introduzidas pelo caractere "&" e cuja substituição é atrasada até que sejam efetivamente analisados ​​e validados). O caractere "%" para introduzir referências de entidade de parâmetro no DTD perde sua função especial fora do DTD e se torna um caractere literal.

No entanto, as referências a entidades de caracteres predefinidas são substituídas onde quer que ocorram, sem a necessidade de um analisador de validação (elas são introduzidas apenas pelo caractere "&").

Declarações de notação

As notações são usadas em SGML ou XML. Eles fornecem uma referência completa a entidades externas não analisadas cuja interpretação é deixada para o aplicativo (que as interpreta diretamente ou recupera a própria entidade externa), atribuindo-lhes um nome simples, que pode ser usado no corpo do documento. Por exemplo, as notações podem ser usadas para fazer referência a dados não XML em um documento XML 1.1. Por exemplo, para anotar imagens SVG para associá-las a um renderizador específico:

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

Isso declara o tipo MIME de imagens externas com este tipo e o associa a um nome de notação "type-image-svg". No entanto, os nomes de notação geralmente seguem uma convenção de nomenclatura que é específica para o aplicativo que gera ou usa a notação: as notações são interpretadas como metadados adicionais cujo conteúdo efetivo é uma entidade externa e um PUBLIC FPI, registrado nos catálogos usados ​​por XML ou Analisadores SGML, ou um URI de SISTEMA, cuja interpretação depende do aplicativo (aqui um tipo MIME, interpretado como um URI relativo, mas pode ser um URI absoluto para um renderizador específico, ou um URN indicando um identificador de objeto específico do sistema operacional, como UUID).

O nome da notação declarada deve ser único em todas as declarações de tipo de documento, ou seja, no subconjunto externo e também no subconjunto interno, pelo menos para conformidade com XML.

As notações podem ser associadas a entidades externas não analisadas incluídas no corpo do documento SGML ou XML. O parâmetro PUBLICou SYSTEMdessas entidades externas especifica o FPI e / ou o URI onde os dados não analisados ​​da entidade externa estão localizados, e o NDATAparâmetro adicional dessas entidades definidas especifica a notação adicional (ou seja, efetivamente o tipo MIME aqui). Por exemplo:

<!DOCTYPE sgml [
  <!ELEMENT sgml (img)*>

  <!ELEMENT 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>

No corpo do documento SGML, essas entidades externas referenciadas (cujo nome é especificado entre "&" e ";") não são substituídas como entidades nomeadas usuais (definidas com um valor CDATA), mas são deixadas como tokens não analisados ​​distintos que podem ser usado como o valor de um atributo de elemento (como acima) ou dentro do conteúdo do elemento, desde que o DTD permita tais entidades externas no tipo de conteúdo declarado de elementos ou no tipo declarado de atributos (aqui o ENTITYtipo para o dataatributo ), ou o analisador SGML não está validando o conteúdo.

As notações também podem ser associadas diretamente a elementos como metadados adicionais, sem associá-los a outra entidade externa, dando seus nomes como valores possíveis de alguns atributos adicionais (também declarados na DTD dentro da declaração do elemento). Por exemplo: <!ATTLIST ...>

<!DOCTYPE sgml [
  <!ELEMENT sgml (img)*>
   <!--
     the optional "type" attribute value can only be set to this notation.
   -->
  <!ATTLIST sgml
    type  NOTATION (
      type-vendor-specific ) #IMPLIED>

  <!ELEMENT img ANY> <!-- optional content can be only parsable SGML or XML data -->
   <!--
     The optional "title" attribute value must be parsable as text.
     The optional "data" attribute value is set to an unparsed external entity.
     The optional "type" attribute value can only be one of the two notations.
   -->
  <!ATTLIST img
    title CDATA              #IMPLIED
    data  ENTITY             #IMPLIED
    type  NOTATION (
      type-image-svg |
      type-image-gif )       #IMPLIED>

  <!--
    Notations are referencing external entities and may be set in the "type" attributes above,
    or must be referenced by any defined external entities that cannot be parsed.
  -->
  <!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 "Title of example1.svg"> <!-- parsed internal entity -->
  <!ENTITY example1SVG      SYSTEM "example1.svg"> <!-- parsed external entity -->
  <!ENTITY example1GIFTitle "Title of example1.gif"> <!-- parsed internal entity -->
  <!ENTITY example1GIF      SYSTEM "example1.gif" NDATA type-image-gif> <!-- unparsed external entity -->
]>
<sgml type="type-vendor-specific">
  <!-- an SVG image is parsable as valid SGML or XML text -->
  <img title="&example1SVGTitle;" type="type-image-svg">&example1SVG;</img>

  <!-- it can also be referenced as an unparsed external entity -->
  <img title="&example1SVGTitle;" data="example1SVG" />

  <!-- a GIF image is not parsable and can only be referenced as an external entity -->
  <img title="&example1GIFTitle;" data="example1GIF" />
</sgml>

O exemplo acima mostra uma notação chamada "type-image-svg" que faz referência ao FPI público padrão e ao identificador do sistema (o URI padrão) de um documento SVG 1.1, em vez de especificar apenas um identificador do sistema como no primeiro exemplo (que foi um URI relativo interpretado localmente como um tipo MIME). Essa anotação é referenciada diretamente no atributo "type" não analisado do elemento "img", mas seu conteúdo não é recuperado. Ele também declara outra notação para um aplicativo específico do fornecedor, para anotar o elemento raiz "sgml" no documento. Em ambos os casos, a notação declarada nomeada é usada diretamente em um atributo "type" declarado, cujo conteúdo é especificado no DTD com o tipo de atributo "NOTATION" (este atributo "type" também é declarado para o elemento "sgml" quanto ao elemento "img").

No entanto, o atributo "title" do elemento "img" especifica a entidade interna "example1SVGTitle" cuja declaração não define uma anotação, portanto, é analisada por analisadores de validação e o texto de substituição da entidade é "Title of example1.svg".

O conteúdo do elemento "img" faz referência a outra entidade externa "example1SVG" cuja declaração também não define uma notação, portanto, também é analisado por analisadores de validação e o texto de substituição da entidade é localizado por seu identificador SYSTEM definido "example1.svg" ( também interpretado como um URI relativo). O conteúdo efetivo para o elemento "img" é o conteúdo deste segundo recurso externo. A diferença com a imagem GIF, é que a imagem SVG é analisada dentro do documento SGML, de acordo com as declarações no DTD, onde a imagem GIF é apenas referenciada como um objeto externo opaco (que não é analisável com SGML) através de seu " data "atributo (cujo tipo de valor é uma ENTITY opaca).

Apenas um nome de notação pode ser especificado no valor dos atributos ENTITY (não há suporte em SGML, XML 1.0 ou XML 1.1 para vários nomes de notação no mesmo ENTITY externo declarado, portanto, atributos separados são necessários). No entanto, várias entidades externas podem ser referenciadas (em uma lista de nomes separados por espaço) em atributos declarados com o tipo ENTITIES, e onde cada entidade externa nomeada também é declarada com sua própria notação).

As notações também são completamente opacas para analisadores XML e SGML, portanto não são diferenciadas pelo tipo de entidade externa que podem fazer referência (para esses analisadores, eles têm apenas um nome único associado a um identificador público (um FPI) e / ou um identificador do sistema (um URI)).

Alguns aplicativos (mas não os próprios analisadores XML ou SGML) também permitem referenciar notações indiretamente, nomeando-as no "URN:''name''"valor de um atributo CDATA padrão, em todos os lugares em que um URI pode ser especificado. No entanto, esse comportamento é específico do aplicativo e requer que o aplicativo mantenha um catálogo de URNs conhecidos para resolvê-los nas notações que foram analisadas em um analisador SGML ou XML padrão. Esse uso permite que as notações sejam definidas apenas em um DTD armazenado como uma entidade externa e referenciado apenas como o subconjunto externo de documentos, e permite que esses documentos permaneçam compatíveis com analisadores XML ou SGML de validação que não têm suporte direto para notações.

As notações não são usadas em HTML ou em perfis básicos para XHTML e SVG, porque:

  • Todas as entidades externas usadas por esses tipos de documento padrão são referenciadas por atributos simples, declarados com o tipo CDATA em seu DTD padrão (como o atributo "href" de um elemento âncora "a" ou o atributo "src" de uma imagem " elemento img ", cujos valores são interpretados como um URI, sem a necessidade de nenhum catálogo de identificadores públicos, ou seja, FPI conhecido)
  • Todas as entidades externas para metadados adicionais são referenciadas por:
    • Atributos adicionais (como type , que indica o tipo MIME da entidade externa, ou o atributo charset , que indica sua codificação)
    • Elementos adicionais (como link ou meta em HTML e XHTML) em seus próprios atributos
    • Pseudo-atributos padrão em XML e XHTML (como xml: lang ou xmlns e xmlns: * para declarações de namespace).

Mesmo na validação de analisadores SGML ou XML 1.0 ou XML 1.1, as entidades externas referenciadas por um FPI e / ou URI em notações declaradas não são recuperadas automaticamente pelos próprios analisadores. Em vez disso, esses analisadores fornecem apenas ao aplicativo o FPI e / ou URI analisado associado às notações encontradas no documento SGML ou XML analisado, e com uma facilidade para um dicionário contendo todos os nomes de notação declarados no DTD; esses analisadores de validação também verificam a exclusividade das declarações de nomes de notação e relatam um erro de validação se alguns nomes de notação forem usados ​​em qualquer lugar no DTD ou no corpo do documento, mas não declarados:

  • Se o aplicativo não puder usar nenhuma notação (ou se seu FPI e / ou URI forem desconhecidos ou não forem suportados em seu catálogo local), essas notações podem ser ignoradas silenciosamente pelo aplicativo ou o aplicativo pode sinalizar um erro.
  • Caso contrário, os próprios aplicativos decidirão como interpretá-los, se as entidades externas devem ser recuperadas e, em seguida, analisadas separadamente.
  • Os aplicativos podem então sinalizar um erro, se tal interpretação, recuperação ou análise separada falhar.
  • As notações não reconhecidas que podem fazer com que um aplicativo indique um erro não devem bloquear a interpretação do documento validado que as usa.

XML DTDs e validação de esquema

A sintaxe XML DTD é uma das várias linguagens de esquema XML . No entanto, muitas das linguagens de esquema não substituem totalmente o XML DTD. Notavelmente, o XML DTD permite definir entidades e notações que não têm equivalentes diretos em XML sem DTD (porque entidades internas e entidades externas analisáveis ​​não fazem parte das linguagens de esquema XML e porque outras entidades externas não analisadas e notações não têm mapeamentos equivalentes simples em maioria das linguagens de esquema XML).

A maioria das linguagens de esquema XML são apenas substitutos para declarações de elementos e lista de atributos declarações, de tal forma que um que se torna possível aos documentos XML analisam com não-validação analisadores XML (se o único propósito do subconjunto DTD externo foi para definir o esquema). Além disso, os documentos para essas linguagens de esquema XML devem ser analisados ​​separadamente, portanto, validar o esquema de documentos XML em modo autônomo puro não é realmente possível com essas linguagens: a declaração do tipo de documento continua necessária para pelo menos identificar (com um Catálogo XML ) o esquema usado no documento XML analisado e que é validado em outro idioma.

Um equívoco comum sustenta que um analisador XML não validador não precisa ler as declarações de tipo de documento, quando, na verdade, as declarações de tipo de documento ainda devem ser verificadas quanto à sintaxe correta, bem como a validade das declarações, e o analisador ainda deve analisar todas as entidades declarações no subconjunto interno e substituem os textos de substituição de entidades internas que ocorrem em qualquer lugar na declaração de tipo de documento ou no corpo do documento.

Um analisador não validador pode, no entanto, optar por não ler entidades externas analisáveis (incluindo o subconjunto externo ) e não tem que honrar as restrições do modelo de conteúdo definidas nas declarações de elemento e nas declarações de lista de atributos.

Se o documento XML depende de entidades externas analisáveis ​​(incluindo o subconjunto externo especificado ou entidades externas analisáveis ​​declaradas no subconjunto interno ), ele deve ser declarado standalone="no"em sua declaração XML . O DTD de validação pode ser identificado usando Catálogos XML para recuperar seu subconjunto externo especificado .

No exemplo abaixo, o documento XML é declarado com standalone="no"porque tem um subconjunto externo em sua declaração de tipo de documento:

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

Se a declaração do tipo de documento XML inclui qualquer identificador SYSTEM para o subconjunto externo, ele não pode ser processado com segurança como autônomo: o URI deve ser recuperado, caso contrário, pode haver entidades de caracteres nomeados desconhecidos cuja definição pode ser necessária para analisar corretamente o XML efetivo sintaxe no subconjunto interno ou no corpo do documento (a análise da sintaxe XML é normalmente realizada após a substituição de todas as entidades nomeadas, excluindo as cinco entidades que são predefinidas em XML e que são substituídas implicitamente após a análise do documento XML em tokens lexicais). Se incluir apenas qualquer identificador PÚBLICO, ele pode ser processado como autônomo, se o processador XML conhecer esse identificador PÚBLICO em seu catálogo local, de onde pode recuperar uma entidade DTD associada.

Exemplo de esquema XML DTD

Um exemplo de um XML DTD externo muito simples para descrever o esquema de uma lista de pessoas pode consistir em:

<!ELEMENT people_list (person)*>
<!ELEMENT person (name, birthdate?, gender?, socialsecuritynumber?)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT birthdate (#PCDATA)>
<!ELEMENT gender (#PCDATA)>
<!ELEMENT socialsecuritynumber (#PCDATA)>

Seguindo linha por linha:

  1. people_listé um nome de elemento válido e uma instância de tal elemento contém qualquer número de personelementos. O *indica que pode haver 0 ou mais personelementos dentro do people_listelemento.
  2. personé um nome de elemento válido e uma instância de tal elemento contém um elemento denominado name, seguido por outro denominado birthdate(opcional), then gender(também opcional) e socialsecuritynumber(também opcional). O ?indica que um elemento é opcional. A referência ao namenome do elemento não tem ?, portanto, um personelemento deve conter um nameelemento.
  3. name é um nome de elemento válido e uma instância de tal elemento contém "dados de caracteres analisados" (#PCDATA).
  4. birthdate é um nome de elemento válido e uma instância de tal elemento contém dados de caractere analisados.
  5. gender é um nome de elemento válido e uma instância de tal elemento contém dados de caractere analisados.
  6. socialsecuritynumber é um nome de elemento válido e uma instância de tal elemento contém dados de caractere analisados.

A seguir, um exemplo de arquivo XML que usa e está em conformidade com este DTD. O DTD é referenciado aqui como um subconjunto externo, por meio do especificador SYSTEM e um URI. Ele assume que podemos identificar o DTD com a referência URI relativa "example.dtd"; a "lista de pessoas" depois de "! DOCTYPE" nos diz que as tags raiz, ou o primeiro elemento definido no DTD, é chamado de "lista de pessoas":

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

Pode-se renderizar isso em um navegador habilitado para XML (como o Internet Explorer ou Mozilla Firefox ) colando e salvando o componente DTD acima em um arquivo de texto denominado example.dtd e o arquivo XML em um arquivo de texto com nome diferente e abrindo o Arquivo XML com o navegador. Os arquivos devem ser salvos no mesmo diretório. No entanto, muitos navegadores não verificam se um documento XML está de acordo com as regras do DTD; eles são necessários apenas para verificar se o DTD está sintaticamente correto. Por razões de segurança, eles também podem optar por não ler o DTD externo.

O mesmo DTD também pode ser incorporado diretamente no próprio documento XML como um subconjunto interno, colocando-o entre [colchetes] na declaração de tipo de documento, caso em que o documento não depende mais de entidades externas e pode ser processado em modo autônomo :

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

Alternativas para DTDs (para especificar esquemas) estão disponíveis:

  • O XML Schema , também conhecido como XML Schema Definition (XSD), alcançou o status de recomendação dentro do W3C e é popular para uso de XML "orientado a dados" (isto é, não publicação transacional) devido à sua tipificação mais forte e rodada mais fácil. tropeçando em declarações Java. A maior parte do mundo editorial descobriu que a complexidade adicional do XSD não traria nenhum benefício particular, então os DTDs ainda são muito mais populares lá. Uma definição de esquema XML é em si um documento XML, enquanto um DTD não é.
  • RELAX NG , que também faz parte do DSDL , é um padrão internacional ISO. É mais expressivo que o XSD, embora forneça uma sintaxe mais simples, mas o suporte a software comercial demorou a chegar.

Segurança

Um XML DTD pode ser usado para criar um ataque de negação de serviço (DoS), definindo entidades aninhadas que se expandem exponencialmente ou enviando o analisador XML para um recurso externo que nunca retorna.

Por esse motivo, o .NET Framework fornece uma propriedade que permite proibir ou ignorar a análise de DTD, e as versões recentes de aplicativos do Microsoft Office (Microsoft Office 2010 e superior) se recusam a abrir arquivos XML que contenham declarações de DTD.

Veja também

Referências

links externos