Lisez-moi S.V.P. 

13 novembre 2000

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 :

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.

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 "&amp;" 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 "&amp;" 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 :

  1. 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() ;
  2. Les applications DOM peuvent offrir des interfaces et des objets supplémentaires, absents de cette spécification, tout en restant conformes au DOM ;
  3. 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.