XML Events
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
W3C

Événements XML

Une syntaxe d'événements pour XML

Recommendation du W3C - 14 Octobre 2003

Cette version :
http://www.w3.org/TR/2003/REC-xml-events-20031014
Dernière version :
http://www.w3.org/TR/xml-events
Version précédente :
http://www.w3.org/TR/2003/PR-xml-events-20030804
Version marquée diff. :
xml-events-diff.html
Éditeurs :
Shane McCarron, Applied Testing and Technology, Inc.
Steven Pemberton, CWI/W3C®
T. V. Raman, IBM Corporation

Veuillez consulter l'errata de ce document, qui peut inclure quelques corrections normatives.

Ce document est également disponible dans ces formats non normatifs : version PostScript, version PDF, archive ZIP, et archive TAR Gzipée.

La version anglaise de cette spécification est la seule version normative. Des traductions non normatives peuvent également être disponibles.


Résumé

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.

Status de ce 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.

Ce document a été produit par le groupe de travail HTML du W3C (membres uniquement), au sein de l'activité HTML. Les buts du groupe de travail HTML sont débattus dans la charte du groupe de travail HTML. Des révélations de brevet concernant cette specification peuvent être trouvées sur la page de révélation des brevets du Groupe de travail.

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).

Contenu

1.Introduction

Cette section est informative.

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 :

Schéma de propagation des événements
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 :

Le DOM spécifie un modèle d'événements qui fournit les propriétés suivantes :

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.

2.Exigences de Conformité

Cette section est normative.

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].

2.1.Conformité du Document

É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 :

  1. Le document doit se conformer aux contraintes définies dans l'Appendice B - Implémentation Schema ou l'Appendice A - Implémentation DTD, en combinaison avec les contraintes définies dans l'implémentation de son langage hôte.

  2. 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 :

    
    

2.2.Conformité du Langage d'Accueil

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.

2.3.Conformité de l'Agent Utilisateur

Un agent utilisateur conforme doit supporter toutes les caractéristiques exigées dans cette recommandation.

3.Le Module Événements XML

Cette section est normative.

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 xmlns xmlns: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ément Attributs Modèle de Contenu Minimal
listener event (NMTOKEN),
observer (IDREF),
target (IDREF),
handler (URI),
phase ("capture" | "default"*),
propagate ("stop" | "continue"*),
defaultAction ("cancel" | "perform"*),
id (ID)
EMPTY

Implémentations: DTD, Schema XML

3.1.L'Élément écouteur

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:

event
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].
observer
L'attribut facultatif observer ("observateur"), spécifie l'id de l'élément avec lequel l'écouteur d'événement est enregistré. Si cet attribut n'est pas présent, l'observateur est l'élément sur lequel l'attribut event se trouve (voir dans la suite "Attacher des Attributs Directement à l'Élément Observateur"), ou le parent de cet élément (voir dans la suite "Attacher des Attributs Directement à l'Élément Gestionnaire").
target
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


où 'para1' est un ancêtre du noeud suivant

The draft document

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.

handler
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").
phase
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.

propagate
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".

defaultAction
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é.

id
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].

3.1.1.Exemples d'Utilisation d'écouteur

  1. 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).

    
    
  2. 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".

    
    
  3. 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.

    
    
  4. Ceci fixe un gestionnaire pour un autre document.

    
    

3.2.Attacher des Attributs Directement à l'Élément Observateur

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.

3.2.1. Exemples d'Utilisation d'Attributs Attachés à un Élément Observateur

  1. Le premier exemple va fixer le gestionnaire identifié par "#popper" à l'élément , et annuler l'action par défaut pour l'événement.

    The document
    
  2. Ceci va fixer le gestionnaire à #handle-overflow pour l'événement overflow, à l'élément courant.

    ...

3.3.Attacher des Attributs Directement à l'Élément Gestionnaire

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.

3.3.1. Exemples d'Utilisation d'Attributs Attachés à un Élément Gestionnaire

  1. Dans ce cas, l'élément est le gestionnaire pour l'événement submit sur l'élément ayant id="form1".

    
    
  2. Dans ce cas, l'élément est le gestionnaire pour l'événement q-submit, et l'observateur est l'élément questionnaire.

    
        
          ...
        
        ...
     
    
  3. L'élément

  4. L'élément est le gestionnaire pour l'événement enterforward. L'élément est l'observateur.

    
        
            
        
        

    Hello!

  5. L'élément est le gestionnaire pour l'événement nomatch. L'observateur est l'élément .

    What is the code word? rutabaga It is the name of an obscure vegetable. Security violation!
  6. Cet exemple montre trois gestionnaires pour différents événements. L'observateur pour les trois est l'élément .

    
        Please enter your password
        
            Mail [email protected] in case of problems
        
        
            A pet's name
        
        
            This field is required
        
    
    

3.4.Cas de l'Absence de l'Attribut Observateur et Gestionnaire

Le tableau suivant résume quels éléments jouent le rôle d'observateur ou de gestionnaire si l'attribut approprié est omis.

Effet de l'omission des attributs observateur et gestionnaire
Gestionnaire présent Gestionnaire omis
Observateur présent (comme déclaré) L'élément est le gestionnaire
Observateur omis L'élément est l'observateur L'élément est le gestionnaire
Le parent est l'observateur

3.5.Gestionnaires d'Événements

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