Une DTD est écrite dans un fichier texte. L’appartenance d’un document XML à une DTD particulière se fait par la déclaration suivante dans le fichier XML.
La déclaration d’un DTD se fait dans un élément XML particulier (qui n’en est pas un…), commençant par <!DOCTYPE et se terminant par >. Le premier mot se trouvant dans cet élément est le nom de la DTD, qui correspond au nom de l’élément racine : web-app dans notre cas. Suit une déclaration, qui indique où se trouve, physiquement, le fichier dans lequel la DTD se trouve. Ce fichier peut se trouver en trois endroits : Suit enfin la déclaration de notre DTD proprement dite : sous forme d’un nom de fichier sur le système local, d’une URL sur le web, ou la DTD elle-même.

Une DTD est une suite de déclarations qui indique la hiérarchie des nœuds et des sous-nœuds de notre document XML. Prenons tout de suite un exemple, en écrivant une DTD à laquelle notre fichier XML se conforme.
Remarquons qu’il aurait été possible de ranger ce nouvel élément dans un fichier marin.dtd (par exemple), et de le référencer de la façon suivante :
Comme leur nom le laisse supposer, les éléments <!ELEMENT > permettent de définir des éléments XML. Cette DTD nous indique que le premier élément XML que l’on doit trouver est un élément marin. Suit dans cet élément <!ELEMENT > une définition du contenu de cet élément. Dans le cas de marin, on lit ( nom, prenom, commentaire). Cela signifie que notre élément marin doit nécessairement contenir trois sous-éléments qui ont pour nom nom, prenom et commentaire, dans cet ordre. Telles que les choses sont déclarées, la présence de ces trois sous-éléments n’est pas facultative, et il ne peut pas y en avoir plusieurs. Leur déclaration à cet endroit signifie que plus loin dans le document DTD, il doit se trouver trois autres <!ELEMENT >, chacun définissant les éléments nom, prenom et commentaire. Ce point est d'ailleurs bien respecté dans notre exemple. La déclaration de nom est différente : <!ELEMENT nom (#PCDATA)>. Elle indique que l’élément nom ne contient pas de sous-élément, mais qu’il contient du texte. Enfin la dernière déclaration, celle de remarque, est référencée par la déclaration d’un attribut : lang. Cet attribut est déclaré dans un élément <!ATTLIST >. Cet élément a pour premier argument le nom de l’élément dans lequel se trouve l’attribut, suivi du nom de l’attribut et de son type. En général le type d’un attribut est CDATA. La dernière déclaration "FR" permet de fixer une valeur par défaut à cet attribut. S’il n’est pas explicitement écrit dans un fichier XML, ou créé au niveau du DOM, il prendra la valeur par défaut FR.

Cette DTD spécifie le contenu des fichiers web.xml dans le cadre de la version 2.3 de l’API servlet. Ce document est téléchargeable sur l'URL http://java.sun.com/dtd/web-app_2_3.dtd. C’est là que les analyseurs XML validant vont aller le chercher, ce qui leur permettra de valider, ou non, que le fichier web.xml considéré est bien conformes aux spécifications. Il est important de savoir lire à l’œil ce genre de document, dans la mesure où c’est souvent le seul moyen de trouver la raison pour laquelle Tomcat refuse de charger une application web, pour cause de web.xml invalide. Ce document contient énormément de commentaires, le premier élément que l’on trouve est le suivant.
Cet élément nous donne la liste de tous les sous-éléments que peut contenir l’élément web-app, l’ordre dans lequel on doit les trouver ainsi que leur cardinalité. Il apparaît donc que si l’on range l’élément listener, qui permet de poser des listeners sur l’ouverture et la fermeture des sessions, après les déclarations des servlets, le document XML ne sera plus valide, et Tomcat refusera de charger l’application web correspondante. L’élément listener est lui-même spécifié un peu plus loin dans ce document.