Qu'est-ce que le modèle objet de document ?

Rédacteurs: Philippe Le Hégaret, W3C; Lauren Wood, SoftQuad Software Inc., président du groupe de travail; Jonathan Robie, Texcel (pour DOM niveau 1)

Introduction

Le modèle objet de document (DOM) est une interface de programmation d'application (API) pour des documents HTML valides et XML bien-formés. Il définit la structure logique d'un document et la manière d'y accéder et de le manipuler. Dans la spécification DOM, le terme document est utilisé dans un sens large (on utilise de plus en plus XML pour représenter de nombreux types d'informations, qui peuvent êtres stockées sur des systèmes variés, et que l'on considèrerait traditionnellement comme des données plutôt que comme des documents. Néanmoins, XML présente ces données comme des documents et on peut utiliser le DOM pour gérer ces données.

Avec le modèle objet de document, les programmeurs peuvent construire des documents, naviguer dans leur structure ainsi qu'ajouter, modifier ou supprimer des éléments et leur contenu. Tout ce qui se trouve dans un document HTML, ou XML, peut être touché, modifié, supprimé ou ajouté en utilisant le modèle objet de document, à quelques exceptions près (notamment, les interfaces DOM pour les sous-ensembles XML internes et externes qui n'ont pas encore été définies).

En tant que spécification du W3C, un objectif important du modèle objet de document est de fournir une interface de programmation standard pouvant être utilisée dans une grande variété d'environnements et d'applications. Le DOM est conçu pour servir avec n'importe quel langage de programmation. Afin de pouvoir offrir une spécification des interfaces DOM précise et indépendante d'un langage, nous avons choisi de les définir dans le langage de définition d'interface (IDL) de l'Object Management Group (OMG) [OMGIDL], comme défini dans la spécification CORBA 2.3.1 [CORBA]. En supplément de OMG IDL, nous proposons des liaisons de langage pour Java [Java] et ECMAScript [ECMAScript] (un langage de script standard de l'industrie basé sur JavaScript [JavaScript] et JScript [JScript]).

Remarque : OMG IDL représente seulement une façon, indépendante du langage et neutre pour la mise en œuvre, de définir des interfaces. On aurait pu se servir d'autres langages de définition d'interface ([COM], [JavaIDL], [MIDL], etc.). En général, les langages de définition d'interface sont conçus pour des environnements informatiques spécifiques. On peut mettre en œuvre le modèle objet de document dans n'importe quel environnement informatique, et il n'impose pas de phases de liaison d'objets généralement associées à ces langages.

Ce qu'est le modèle objet de document

Le DOM est une interface de programmation (API) pour des documents. Elle se fonde sur une structure objet qui ressemble de près à la structure des documents qu'elle modélise. Par exemple, considérons cette table, tirée d'un document HTML :

      <TABLE>
      <TBODY> 
      <TR> 
      <TD>Bois ombragé</TD>
      <TD>Éolien</TD> 
      </TR> 
      <TR>
      <TD>Au cours de l'eau, Charlie</TD>        
      <TD>Adrien</TD> 
      </TR> 
      </TBODY>
      </TABLE>

Une représentation graphique DOM de cet exmple de table :

Représentation graphique du DOM de la table exemple

Représentation graphique DOM de l'exemple de table

Dans le DOM, les documents ont une structure logique qui ressemble beaucoup à un arbre ; plus précisément, qui est comme une forêt ou un bosquet, pouvant contenir plusieurs arbres. Chaque document contient un nœud de type de document ou aucun, un nœud d'élément racine et zéro ou plus commentaires ou instructions de traitement ; l'élément racine sert comme origine de l'arbre d'éléments du document. Toutefois, le DOM ne spécifie pas que les documents doivent être mis en œuvre comme un arbre, ou un bosquet, ni comment les relations entre les objets doivent l'être. Le DOM est un modèle logique qui peut être mis en œuvre de toute façon pratique. Dans cette spécification, nous utilisons le terme modèle de structure pour décrire la représentation en arborescence d'un document. Nous employons également le terme arbre en référence à l'ordonnancement de ces éléments d'information qui peuvent être touchés (à l'exclusion des attributs) en se servant de méthodes de cheminement dans l'arbre. Une propriété importante des modèles de structure DOM est l'isomorphisme structurel : si on emploie deux mises en œuvre du modèle objet de document pour créer une représentation du même document, celles-ci créeront le même modèle de structure, conformément à l'ensemble d'information XML [Infoset].

Remarque : Il peut y avoir quelques divergences selon l'interpréteur utilisé pour construire le DOM. Par exemple, le DOM peut ne pas avoir de blancs dans le contenu d'un élément si l'interpréteur les écartent.

On a choisi le nom modèle objet de document parce qu'il s'agit d'un modèle objet dans le sens traditionnel de la conception orientée objet : les documents sont modélisés en utilisant des objets et le modèle englobe non seulement la structure du document mais également son comportement et les objets qui le composent. En d'autres termes, les nœuds, dans la figure précédente, ne représentent pas une structure de données : ils représentent des objets qui ont des fonctions et une identité. Comme modèle objet, le DOM identifie :

les interfaces et les objects utilisés pour représenter et manipuler un document ;
la sémantique de ces interfaces et de ces objets, y compris leurs comportements et attributs ;
les relations et collaborations entre ces interfaces et objets.

La structure des documents SGML est traditionnellement représentée par un modèle de données abstrait, non par un modèle objet. Un modèle de données abstrait s'articule autour des données. Dans les langages orientés objet, les données elles-même sont encapsulées dans des objets qui cachent celles-ci, les protégeant d'une manipulation directe de l'extérieur. Les fonctions associées à ces objets déterminent comment ces objets peuvent être manipulés, et elles font partie du modèle objet.

Ce que le modèle objet de document n'est pas

Cette section permet une compréhension plus fine du DOM, en distinguant celui-ci d'autres systèmes ressemblants.

Le modèle objet de document n'est pas une spécification binaire. Les programmes DOM écrits dans la même liaison de langage auront leur code source compatible d'une plateforme à l'autre, mais le DOM ne définit aucune forme d'interopérabilité binaire ;
Le modèle objet de document n'est pas un moyen de faire persister des objets XML ou HTML. Au lieu de définir comment les objets peuvent être représentés en XML, le DOM déinit comment les documents XML et HTML sont représentés en tant qu'objets qui peuvent être utilisés, par conséquent, dans des programmes orienté objet ;
Le modèle objet de document n'est pas un jeu de structures de données : c'est un modèle objet qui définit des interfaces. Bien que le présent document contienne des schémas représentant des relations parents/enfants, il s'agit de relations logiques définies par les interfaces de programmations, non des représentations de structures de données internes particulières ;
Le modèle objet de document ne définit pas, dans un document, quelle information est concernée ou comment celle-ci est structurée. Pour XML, c'est le rôle de l'ensemble d'information XML du W3C [Infoset]. Le DOM est juste une interface (API) vers cet ensemble d'information ;
Le modèle objet de document, en dépit de son nom, n'est pas en compétition avec le modèle objet de composant (COM). COM, tout comme CORBA, est une façon indépendante d'un langage de définir des interfaces et des objets ; le DOM est un jeu d'interfaces et d'objets conçu pour la gestion de documents HTML et XML. On peut mettre en œuvre le DOM en utilisant des systèmes indépendants du langage comme COM ou CORBA ; on peut également le mettre en œuvre en utilisant des liaisons spécifiques aux langages, comme celles définies dans ce document pour les langages Java et ECMAScript.

L'origine du modèle objet de document

Le DOM trouve son origine en tant que spécification pour que les scripts JavaScript et les programmes Java puissent être portés d'un navigateur Web à l'autre. Le modèle objet de document dérive directement du HTML dynamique, envisagé principalement pour les navigateurs. Toutefois, lorsque le groupe de travail DOM a été mis en place au W3C, des vendeurs issus d'autres domaines sont venus y participer, comprenant des éditeurs HTML ou XML et leurs bases documentaires. Plusieurs de ces vendeurs possédaient une expérience de travail avec SGML, avant le développement de XML ; le DOM a donc été influencé par les bosquets SGML (N.D.T. SGML Groves) et le standard HyTime. Certains d'entre eux avaient déjà développé leur propre modèle objet de document afin de fournir une interface (API) aux éditeurs SGML/XML, ou bien de constituer une base documentaire, et ces modèles objet ont aussi influencé le DOM.

Les entités et DOM Core

Dans les interfaces fondamentales du DOM, il n'existe pas d'objets représentant des entités. Les appels numériques de caractère et les appels d'entités prédéfinies de HTML et XML sont remplacés par le caractère unique qui se substitue à l'entité. Par exemple :

        <p>Voici un chien &amp; un chat</p>

Dans cet extrait, l'expression "&" sera remplacée par le caractère "&" et l'élément P formera une seule séquence continue de caractères. Comme les appels numériques de caractères et d'entités prédéfinies ne sont pas reconnus en tant que tels dans les sections CDATA ou dans les éléments SCRIPT et STYLE en HTML, elles ne sont pas remplacées par le caractère unique auquel qui s'y rapporte. Si l'extrait ci-dessus était englobé dans une section CDATA, l'expression "&" ne serait pas remplacée par "&" ni l'expression <p> reconnue comme balise ouvrante. La représentation des entités générales, internes comme externes, est définie dans les interfaces étendues (XML) de DOM niveau 1 [DOM niveau 1].

Remarque : Lorsque la représentation DOM d'un document est sérialisée en un texte XML, ou HTML, les applications devront vérifier chaque caractère, dans les données textuelles, pour déterminer s'il faudra le masquer en utilisant une entité numérique ou prédéfinie. Ne pas le faire pourra donner un document HTML, ou XML, invalide. En outre, les mises en œuvre devraient savoir qu'une sérialisation dans un codage de caractères ("charset") ne couvrant pas entièrement le codage ISO 10646 peut échouer s'il existe des caractères, dans le balisage ou les sections CDATA, absents de ce codage.

La conformité

Cette section expose les divers niveaux de conformité avec DOM niveau 2. La spécification DOM niveau 2 se compose de quatorze modules. Une conformité à DOM niveau 2 ou à un de ses modules est possible.

Une mise en œuvre est conforme à DOM niveau 2, si elle gère le module Core, défini dans ce document (cf. Les interfaces fondamentales). Une mise en œuvre est conforme à un module de DOM niveau 2, si elle gère toutes les interfaces et la sémantique associées à ce module.

Voici la liste complète des modules de DOM niveau 2 et leurs fonctionnalités. Les noms de ces fonctionnalités sont insensibles à la casse.

Le module de base: définit la fonctionnalité "Core".
Le module XML: définit la fonctionnalité "XML".
Le module HTML: définit la fonctionnalité "HTML" →vf (voir [DOM niveau 2 HTML]).
Remarque : Au moment de la publication, ce module DOM niveau 2 n'a pas encore accédé au statut de recommandation du W3C.
Le module de vues: définit la fonctionnalité "Views" →vf dans [DOM niveau 2 Views].
Le module de feuilles de style: définit la fonctionnalité "StyleSheets" →vf dans [DOM niveau 2 StyleSheets].
Le module CSS: définit la fonctionnalité "CSS" →vf dans [DOM niveau 2 CSS].
Le module CSS2: définit la fonctionnalité "CSS2" →vf dans [DOM niveau 2 CSS].
Le module des événements: définit la fonctionnalité "Events" →vf dans [DOM niveau 2 Events].
Le module des événements de l'interface utilisateur: définit la fonctionnalité "UIEvents" →vf dans [DOM niveau 2 Events].
Le module des événements de souris: définit la fonctionnalité "MouseEvents" →vf dans [DOM niveau 2 Events].
Le module des événements de mutation: définit la fonctionnalité "MutationEvents" →vf dans [DOM niveau 2 Events].
Le module des événements HTML: définit la fonctionnalité "HTMLEvents" →vf dans [DOM niveau 2 Events].
Le module de portée: définit la fonctionnalité "Range" →vf dans [DOM niveau 2 Range].
Le module de traversée: définit la fonctionnalité "Traversal" →vf dans [DOM niveau 2 Traversal].

Une mise en œuvre DOM ne doit pas retourner une valeur "true" en réponse à un appel de la méthode hasFeature(feature, version) de l'interface DOMImplementation, pour la fonctionnalité en question, à moins d'être conforme à ce module. Le numéro de version pour toutes les fonctionnalités proposées dans DOM niveau 2.0 est "2.0".

Les interfaces et les mises en œuvre DOM

Le DOM définit des interfaces qui peuvent être utilisées pour gérer des documents XML ou HTML. Il est important de considérer ces interfaces comme des abstractions ; un peu comme les classes de base abstraites en C++, ce sont des moyens de définir la façon d'accéder et de manipuler la représentation interne du document dans l'application. Une interface n'implique pas une mise en œuvre concrète spécifique. Chaque application DOM est libre de maintenir les documents selon une représentation qui soit pratique, tant que les interfaces présentées dans cette spécification sont gérées. Certaines mises en œuvre DOM sont des programmes existants qui utilisent les interfaces DOM pour accéder à un logiciel créé bien avant l'existence de la spécification DOM. Le DOM est donc conçu pour éviter les dépendances de mise en œuvre , notamment :

Les attributs définis en IDL n'impliquent pas d'objets concrets devant avoir des membres de données particuliers ; dans les liaisons de langage, ils se traduisent par un couple de fonctions get()/set(), et non par un membre de données. Dans les liaisons de langage, les attributs en lecture seule n'ont qu'une fonction get() ;
Les applications DOM peuvent offrir des interfaces et des objets supplémentaires, absents de cette spécification, tout en restant conformes au DOM ;
Puisqu'on définit des interfaces et non des objets effectifs à créer, le DOM ne peut pas déterminer le constructeur à appeler pour une mise en œuvre. En général, les utilisateurs du DOM appellent une des méthodes createmot-clé() de la classe Document pour créer des structures de document et, de leur côté, les mises en œuvre DOM créent leurs propres représentations internes de ces structures dans leur interprétation de ces fonctions createmot-clé().

Les interfaces du niveau 1 ont été étendues pour offrir à la fois une fonctionnalité de niveau 1 et de niveau 2.

Les mises en œuvre DOM, dans des languages autres que Java ou ECMAScript, peuvent choisir des liaisons qui soient appropriées et naturelles pour leur langage et leur environnement de déploiement. Par exemple, certains systèmes peuvent créer une classe Document2, héritant de la classe Document, qui contient des méthodes et des attributs nouveaux.

La spécification DOM niveau 2 ne définit aucun mécanisme multiprocessus.