Ce document est la traduction en français de la Recommandation du W3C
portant sur les Événements XML (14 Octobre 2003).
Cette recommandation est une version traduite qui peut comporter des
erreurs. La seule version normative et originale est la version
anglaise, qui se trouve à : http://www.w3.org/TR/2003/REC-xml-events-20031014
Le module Événements XML défini dans cette spécification fournit des langages XML permettant d'intégrer uniformément des écouteurs d'événements et les gestionnaires d'événements associés aux interfaces d'événements du Modèle de Document Objet (DOM)
niveau 2 [DOM2EVENTS]. Le résultat doit fournir une manière inter-opérable d'associer des comportements au balisage de niveau document.
Ce chapitre décrit le statut de ce document au moment de sa publication. D'autres documents pourront remplacer ce document. Une liste des publications courantes du W3C et les dernières révisions de ce rapport technique peuvent être trouvées dans l'index des rapports techniques du W3C à l'adresse http://www.w3.org/TR/.
Ce document est une Recommendation du W3C. Il a été revu par les membres du W3C et les tiers concernés, et a été approuvé par le Directeur comme recommandation du W3C. C'est un document stable qui peut être utilisé comme matériel de référence ou cité comme norme de référence par un autre document. Le rôle du W3C, en produisant cette recommandation, est de mettre en lumière la spécification et d'en promouvoir le plus large déploiement. Ceci permet d'améliorer la fonctionnalité et l'interopérabilité du Web. Une suite de test pour XML Events a
été dévelopée en tant que partie d'une suite publique de test pour XForms 1.0, avec un
rapport d'implémentation.
Merci de rapporter les erreurs de cette spécification à [email protected] (archive). Il est inapproprié d'envoyer des emails de discussion à cette addresse. Les discussions publiques peuvent être tenues sur [email protected] (archive).
Un événement est une représentation d'une certaine occurence asynchrone (comme un clic de souris sur la présentation de l'élément, ou une erreur arithmétique dans la valeur d'un attribut de l'élément, ou un des innombrables autres possibilités), qui est associée à un élément (ciblée vers lui) au sein d'un document XML.
Dans le modèle DOM d'événements [DOM2EVENTS], lorsque un événement se produit, le comportement général consiste à l'expédier,
au cours d'une phase nommée capture, en le passant en bas de l'arbre de document à l'élément dans lequel l'événement s'est produit (appelé sa cible), d'où il peut être renvoyé en haut de l'arbre lors d'un phase appelée bouillonnement. En
général, un événement peut obtenir une réponse en tout élément du chemin (un observateur) dans l'une ou l'autre phase, en causant une action, et/ou en stoppant l'événement, et/ou en annulant l'action par défaut pour cet événement. Le schéma suivant illustre cela :
Passage des événements dans DOM2 : un événement ciblé sur un élément (marqué 'cible') dans l'arbre descend l'arbre de la racine jusqu'à la cible, dans une phase appelée 'capture'. Si le type d'événement
le permet, l'événement remonte alors l'arbre en employant la même route, au cours d'une phase nommée 'bouillonnement'. Tout noeud sur la route, y compris le noeud racine et la cible, peut être un 'observateur' : cela signifie qu'un gestionnaire peut lui être attaché et être activé lorsque l'événement le traverse, dans l'une ou l'autre des deux phases. Un gestionnaire ne peut écouter que pour une seule phase. Afin d'écouter pour les deux, il fait attacher deux gestionnaires.
Une action est une certaine manière de répondre à un événement; un gestionnaire est une certaine spécification pour une telle action, par exemple en utilisant des scripts ou une autre quelconque méthode. Un écouteur est une fixation entre un tel gestionnaire et un événement visant un certain élément dans un document.
HTML [HTML4] associe des événements à un élément en encodant le nom de l'événement en un nom d'attribut, de telle sorte que la valeur de l'attribut est l'action pour cet événement sur
cet élément. Cette méthode a deux désavantages principaux : premièrement elle intègre les événements dans le langage, de telle sorte que pour ajouter un nouvel événement, vous devez procéder à des changements dans le langage, et deuxièmement cela vous force
à mélanger le contenu du document et les spécifications de script et de gestion d'événement, au lieu de vous permettre de les séparer. SVG [SVG] utilise une
méthode similaire.
Le processus de définition d'une nouvelle version de HTML mit en évidence la nécessité d'une méthode extensible de spécification d'événement. Les exigences de conception étaient les suivantes :
Exposer syntaxiquement le modèle d'événement de DOM à un document XML [XML].
Prévoir de nouveaux types d'événement sans nécessiter la modification du DOM ou de la DTD.
Permettre une intégration à d'autres langages XML.
Le DOM spécifie un modèle d'événements qui fournit les propriétés suivantes :
Un système d'événements générique,
Moyens d'enregistrer des écouteurs et des gestionnaires d'événements,
Moyens de router des événements au travers d'une structure d'arbre,
Accéder à une information de contexte pour chaque événement, et
Une définition de passage d'événements, comme esquissée ci-dessus.
L'élément listener et ses attributs, définis dans cette spécification, sont la méthode pour relier un événement DOM niveau 2 à un élément ou à un gestionnaire d'événements. Ils encapsulent divers aspects de
l'interface d'événements de DOM niveau 2, fournissant de ce fait une spécification niveau-balise des actions à effectuer pendant les différentes phases de la propagation d'événements.
Ce document ne spécifie aucun événement particulier, ni ne conseille aucune méthode particulière pour spécifier des actions. Ces définitions sont laissées à n'importe quel langage à balises, en utilisant les mécanismes décrits
ici.
Dans ce document, les mots-clés « DOI(VEN)T », « NE DOI(VEN)T PAS », « REQUIS », « DEVRA », « NE DEVRA PAS », « DEVRAIT », « RECOMMANDÉ », « PEUT » et « OPTIONNEL » doivent s'interpréter comme décrit dans le document [RFC2119].
Événements XML n'est pas un type de document autonome. C'est destiné à être intégré à d'autres langages d'accueil, comme XHTML. Un document conforme "Événements XML" est un document qui requiert uniquement les
caractéristiques décrites comme obligatoires dans cette spécification, et les caractéristiques décrites comme obligatoires dans son langage d'accueil. Un tel document doit respecter tous les critères suivants :
Le document doit contenir une déclaration xmlns pour l'espace nominatif des Événements XML [XMLNAMES]. Par définition, l'espace nominatif pour les Événements XML est
http://www.w3.org/2001/xml-events. Un exemple de balise de début d'un élément racine pourrait être :
Quand les événements XML sont inclus dans un langage d'accueil, toutes les possibilités décrites dans cette specification doivent être incluses dans le langage d'accueil. En outre, les éléments et attributs définis dans
cette spécification doivent être inclus dans le modèle de contenu du langage d'accueil.
Cette spécification définit un module nommé Événements XML. Le module Événements XML utilise l'identificateur
http://www.w3.org/2001/xml-events pour l'espace de nommage de XML [XMLNAMES].
Les exemples de ce document qui utilisent le préfixe d'espace de nommage "ev" présupposent tous une déclaration xmlnsxmlns:ev="http://www.w3.org/2001/xml-events" en un endroit adapté
du document concerné. Tous les exemples sont informatifs.
Le reste de ce chapitre décrit les éléments et les attributs dans ce module, la sémantique, et fournit une définition abstraite de module comme exigé dans [XHTMLMOD].
Le module Événements XML supporte les élément et attributs suivants :
L'Élément listener supporte un sous-ensemble de l'interface EventListener du DOM. Il est utilisé pour déclarer les écouteurs d'événements et les enregistrer par des noeuds spécifiques dans le DOM, et il a
les attributs suivants:
L'attribut event ("événement"), requis, spécifie le type d'événement pour lequel l'écouteur est enregistré. Comme spécifié par [DOM2EVENTS], la valeur
de l'attribut devrait être un Nom XML [XML].
L'attribut facultatif target ("cible"), spécifie l'id de l'élément cible de l'événement (i.e., le noeud qui a causé cet événement). Si cet attribut est présent, seul les événements qui
respectent à la fois l'attribut event et l'attribut target seront traités par le gestionnaire d'événement associé. Clairement en raison de la manière dont les événements se propagent, l'élément cible devrait être un
noeud descendant de l'élément observateur, ou l'élément observateur lui-même.
L'utilisation de cet attribut exige du soin; par exemple, si vous indiquez
et que l'utilisateur clique justement sur le mot "draft", c'est l'élément qui sera la cible, et non le . Ainsi le gestionnaire ne sera pas activé; pour traiter
tous les clics de souris sur l'élément et ses descendants, utilisez observer="link1", et non l'attribut target.
L'attribut facultatif handler ("gestionnaire") spécifie la référence URI d'une ressource et définit l'action qui devrait être effectuée si l'événement atteint l'observateur. (Cette spécification ne fixe pas la forme que
l'élément devrait prendre: voir la section "Gestionnaires d'Événements"). Si cet attribut n'est pas présent, le gestionnaire est l'élément sur lequel l'attribut
event se trouve (voir "Attacher des Attributs Directement à l'Élément Gestionnaire").
L'attribut facultatif phase spécifie quand (au cours de quelle phase de la propagation de l'événement DOM 2) l'écouteur va être activé par l'événement désiré.
capture
L'écouteur est activé durant la phase de capture.
default
L'écouteur est activé durant la phase de bouillonement ou de cible.
La valeur par défaut est phase="default".
Notez bien que tous les événements ne comportent pas une phase de bouillonnement, auquel cas avec phase="default" vous ne pouvez traiter l'événement qu'en faisant de l'observateur la cible de l'événement.
L'attribut facultatif propagate indique si après le traitement de tous les écouteurs du noeud courant, l'événement est autorisé à continuer son chemin (dans la phase de capture ou dans la phase de bouillonnement).
stop
La propagation de l'événement s'arrête
continue
La propagation de l'événement se poursuit (jusqu'à ce qu'elle soit stoppée par d'autres moyens, comme un script, ou par un autre écouteur).
Le comportement par défaut est propagate="continue".
L'attribut facultatif defaultAction indique si après le traitement de tous les écouteurs de l'événement, l'action par défaut pour l'événement (s'il y en a une) devrait être effectuée ou pas. En XHTML par exemple, l'action par défaut pour un clic de souris sur un élément ou sur l'un de ses descendants, est de suivre le lien.
cancel
si le type d'événement est annulable, l'action par défaut est annulée
perform
l'action par défaut est effectuée (jusqu'à ce qu'elle soit annulée par d'autres moyens, comme un script, ou par un autre écouteur).
La valeur par défaut est defaultAction="perform".
Remarquez que tous les événements ne sont pas annulables, auquel cas l'attribut est ignoré.
L'attribut facultatif id est un identificateur unique de document. La valeur de cet identificateur est souvent utilisée pour manipuler l'élément au travers d'une interface DOM.
Notez bien que observer = "" et event = "" sont identiques à l'attribut begin = "." dans la
temporisation des événements SMIL [SMIL20].
Cet exemple fixe dans l'élément le gestionnaire à "#doit", qui sera activé lorsque l'événement activate se produit sur l'élément ayant id="button1",
ou sur l'un de ses descendants. L'activation se produira pendant le bouillonnement ou, si l'événement s'est produit sur l'élément observateur lui-même, lorsque l'événement atteint l'élément (phase cible).
Ceci fixe le gestionnaire à #overflow-handler, qui sera activé lorsque l'événement overflow se produit sur l'élément ayant id="expr1" et remonte vers l'élément avec id="prog1".
Ceci fixe le gestionnaire à #popup, qui sera activé lorsque un événement activate se produit sur l'élément ayant id="embargo" ou sur l'un de ses descendants. Comme il sera activé durant la phase de capture, et que la propagation est alors stoppée, cela aura l'effet (indépendamment de ce que fait le gestionnaire) d'empêcher tout élément descendant de embargo
de voir un événement activate.
Tous les attributs de l'élément listener, à l'exception de id, peuvent être utilisés comme attributs globaux, comme défini dans les Espaces de Nommage en XML [XMLNAMES], afin d'attacher les attributs à d'autres éléments.
Notez que ceci signifie que l'élément est à proprement parler redondant, dans la mesure où
aurait le même effet que
Néanmoins, par soucis de commodité, l'élément a été conservé.
Si l'attribut observer est omis (mais pas l'attribut handler), alors l'élément auquel les autres attributs sont attachés est l'élément observateur.
Si, en attachant les attributs globaux à un élément, l'attribut handler est omis, alors l'élément auquel les autres attributs sont attachés est l'élément gestionnaire.
Remarquez que, comme les attributs observer et target sont des IDREFs, les éléments gestionnaire et observateur/cible doivent dans ce cas se trouver dans le même document (alors que dans les autres cas,
l'attribut handler étant une URI, l'élément gestionnaire peut être dans un autre document).
Si l'attribut observer est omis, alors le parent de l'élément gestionnaire est l'élément observateur.
Cette spécification ne nécessite pas qu'une application XML utilisant les Événements XML utilise une méthode précise pour spécifier des gestionnaires. Toutefois, les exemples, et en particulier ceux du paragraphe
"attacher des attributs directement au gestionnaire", sont destinés à donner des exemples de la manière selon laquelle les gestionnaires pourraient être spécifiés.
Il est malgré tout reconnu que deux méthodes sont susceptibles d'être souvent appliquables : la création de scripts (comme l'élément
