Abstract
XML vocabularies like XHTML have traditionally provided event-specific tags and attributes designed to allow the creation of specific types of interactions within an XHTML document. Module XML-Events has been designed to create a generic extensible mechanism for authoring DOM2 event listeners and attaching them to event handlers in different XML vocabularies. In this paper, we describe how module XML-events can be integrated into XML vocabularies to augment them with interaction behavior. When combined with the XML DOM, module XML Events can turn a DOM2-conformant XML browser into a powerful container for hosting XML-based applications. We illustrate this design metaphor by means of sample XML applications that have been used to test a prototypical XML-Events implementation.
XML documents as defined by [XML 1.0]can encode structured data as well as structure documents. Thus, at its most general, XML 1.0 can be viewed as a universally agreed upon syntax for encoding and transmitting syntactic expressions (s-expressions).
Syntactic expressions come into their own when combined with a flexibile means of attaching behavior to the structured data being encoded by the s-expression. Such behavior typically results from the semantics implemented by application code that consumes the s-expression. Thus, the syntactic expression <person>...</person> might encode a person object; Different pieces of application code that consume this syntactic expression might implement different aspects of the desired semantics e.g., by inserting the appropriate data record into a database, or by generating a human-readable display of the data encapsulated by the markup. Application code that implements such semantics at the user-interface typically provides interaction behavior in addition to producing human-readable presentations. Thus, the presentation ---combined with the interaction semantics--- determines the look and feel of object <person>...</person>.
Bringing syntactic expressions to life therefore involves binding the s-expression to application code that implements the relevant semantics. Batch-processing behavior such as inserting the encoded data into a database is typically achieved by binding data object <person>...</person> to a person database record. Interaction semantics might be bound by creating custom vertical vocabularies and implementing browsers that consume such vertical vocabularies to provide the desired user interaction.
WWW browsers for languages like XHTML and SVG can be viewed with respect to the above model as binding interaction semantics to the input markup language. In this context, XHTML is intentionally designed to be a generic host language ---as opposed to being an application-specific vertical vocabulary. The XHTML browser in particular, and XML browser in general can therefore be viewed as an application container.
A first requirement of a generic application container designed to host user interaction is the ability to process and dispatch events in a consistent manner across applications hosted by the container. W3C DOM Events were designed to meet this need; interface EventListener [DOM2 Events] defines a generic event handling mechanism for use in XML browsers. Module [XML-Events] exposes this functionality to the XML author by defining a generic event syntax for XML. This enables XML-based languages to define custom event semantics without having to extend the underlying markup language ---a key requirement for being able to host XML-based applications in a browser.
This section presents a brief overview of the functionality provided by module XML-Events. Normative definitions of interface EventListener and the XML constructs introduced by module XML-Events are found in the relevant W3C specifications; this paragraph presents a high-level view of these facilities.
Interaction behavior as perceived by the end-user is typically determined by how a system reacts to asynchronous occurrences actuated by a specific user action, e.g., a mouse click, or by some system response to a change of state. We define events to be the abstract representation of such asynchronous occurrences. Here are examples of events in this model:
| Set focus |
| Mouse click |
| Onset of speech input |
| Silence from user |
| System detects invalid input |
Such events typically occur at a given node of the XML document. The node at which the event occurs is called the target node. Thus, when the user clicks on a button when viewing an XHTML document within a WWW browser, this triggers a dom-click event targetted at the <button> node appearing in the XHTML document.
We first describe the DOM model for event processing. Events are dispatched by passing the event down the document tree starting at the root to the element that is the target node of that event. This is called the capture phase. When the event arrives at the target, it may be passed back up the tree again in the phase called bubbling until it arrives back at the root. An event can be handled at any node occurring along the path travelled by the event in the capture and bubbling phases described here. Nodes that occur along this path can register to be notified during the bubbling or capture phase of events of a given type that target a given node; nodes that register in this manner are called observers. Observers provide event handlers to be invoked upon receiving the desired event; such event handlers can respond to the event by executing the behavior specified. Additionally, handlers can influence further processing of the event, e.g., by stopping event propagation. Thus, in the case of today's XHTML browsers, a mouse-click is an event; the XHTML node that constitutes the markup of the document where the mouse click occurred is the target; the piece of Javascript that is triggered is the event handler.
Module XML-Events defines the necessary XML syntax needed to allow the XML author to specify interaction behavior using the DOM Events model described above. Where today's XHTML 1.1 hard-wires specific event names as attribute names on elements e.g., onmouseover on element img, module XML-Events provides an extensible event syntax that obviates the need to revise the underlying markup language when new event types are added. As an example, the XHTML 1.1 <img onmouseover="#handler" .../> would be rephrased as <img ev:event="onmouseover" ev:handler="#idref".../>. Note that here, global attributes ev:event and ev:handler defined by module XML-Events are added to element img. Notice further that attaching a handler for a new type of event e.g., ev:event="onSpeech" does not require extending the content model of element img. Thus, module XML-Events defines elements and attributes that can be used in declaring event listeners and connecting these event listeners to the appropriate event handler to be invoked upon receiving the desired event.
Viewed from the perspective of an XML browser that implements DOM interface EventListener, these facilities enable XML authors to create custom behaviors for XML content. Interaction behaviors are authored declaratively by specifying the association between nodes in the XML document, events that are of interest, and the handlers to be invoked upon receiving a specific event targetting a given node. The XML browser need only provide the wiring-up of the event to the specified handler. Typically, handlers would be written either in a scripting language, e.g., JavaScript or Python, in which case the XML browser would need access to an appropriate language interpreter for invoking the handler; alternatively, standard handlers can be prescribed as declarative XML markup. The latter approach is used in the sample application shown in this paper; a similar approach is deployed extensively within W3C XForms [see XForms 1.0]
Thus, an XML-browser can be viewed as an interpreter capable of reacting to asynchronous events and invoking author-specified behaviors upon observing such events. Applications designed using this design pattren derive their power from the underlying generic event model, and the ability to attach custom handlers to standard events. Attaching such custom handlers can bring s-expressions to life as described in the introduction.
In this section, we present an implementation of the DOM2 event processing model described above. This event dispatch is then integrated into a prototype XML browser to enable the functionality provided by module XML-Events. This requires:
| An implementation of DOM2 interface EventListener. |
| Implementation of an event dispatch algorithm that allows for event propagation and activation of listeners. |
| Interpretation of XML authored events. |
Based on these requirements,the prototype Java implementation consists of the following:
| Classes that implement DOM interfaces EventListener, EventTarget and Event. |
| Class EventController that implements methods for registering event listeners, propagating events and activating appropriate event handlers. |
| Class Interpreter that interprets XML authored events, instantiates event listeners and registers them with an instance of class EventController . |
When an XML document is first loaded, the associated instance of class Interpreter locates all instances of XML-authored event listeners. As specified by module XML-Events, such declarations can be authored either by using element listener, or by placing global attributes ev:event, ev:observer and ev:handler on elements as appropriate to create a (element, event, handler) triple. The interpreter instantiates EventTarget, EventListener and EventHandler for each such triple and registers the created EventTarget instances with an instance of class EventController that is responsible for implementing the event dispatch loop for this interpreter instance.
DOM events generated during user interaction are received by the XML interpreter and handed to the contained instance of class EventController. Class EventController implements the DOM Event dispatch described earlier. Given an event targetted at a given node, EventController first computes the path from the root to the target and stores this information in the Event instance. EventController then dispatches the event down the document tree, implementing the capturing and bubbling phases respectively.
Class EventController implements a generic DOM event dispatch loop that recursively propagates a DOM event through the document tree along the path computed and stored in the Event instance. In addition to its EventTarget node, each instance of Event encapsulates a CurrentTarget node that allows the EventController to track the progress of event propagation. During event propagation, the EventController updates this CurrentTarget by setting it to the next node in the event's path. The algorithm terminates when all nodes in the event's path have been visited. During the capture phase, only event listeners that have their phase set to capture are activated; EventListeners whose capture property is not set or set to default, are activated during the bubbling phase. Activating an event listener results in the associated handler being invoked. As described, this invocation can additionally affect further propogation of the event through the event dispatch loop.
Consider an application that allows users to display, update and save their CD collection online. We present such an application using a custom XML vocabulary called ToyML. Since the focus here is on the interaction behavior implemented via XML-Events, we will asume that the host XML browser is capable of displaying XML content authored in ToyML ---perhaps using an appropriate style sheet.
Module XML-Events allows the declaration of handlers that implement desired interaction behavior, and the wiring-up of such handlers to the XML content as described earlier. We leverage this in authoring the interaction semantics required by this application. The generic nature of DOM event interfaces then enables the XML browser hosting the ToyML application to respond to DOM events by dispatching the event through the document, and invoking the user-authored handler to implement the desired interaction semantics.
XML vocabulary ToyML defines the following elements for encoding a collection of music CDs:
Element music for holding music collections.
Element genre for holding collections of a particular genre.
Element collection for holding a CD collection.
Element cd for holding a music CD.
Element button similar to the HTML element of the same name; it allows user-triggered actions.
Declarative handlers view, add and delete can be used to view, add or delete a CD from a collection. Appendix ToyML Schema defines language ToyML via an XML Schema.
Below, we show an XML fragment document that encodes two CD collections, for the two different classical genre.
Example 1. Music CD Collection
<toyml:music id="m1">
<toyml:genre name="classical" id="cl1">
<toyml:colection id="v1" type="vocal" artist="Christa Ludwig">
<toyml:cd> Les Introuvables </toyml:cd>
...
</toyml:colection>
<toyml:collection id="i1" type="instrumental" artist="Chopin">
<toyml:cd> Nocturnes </toyml:cd>
...
</toyml:collection>
...
</toyml:genre>
</toyml:music>
The following ToyML markup might be used to add, delete and view cds in the Musics Inventory application.
Example 2. Music Inventory UI
<toyml:music id="m1">
...
<toyml:colection id="v1" type="vocal" artist="Christa Ludwig">
...
<toyml:button id="b1">
<toyml:caption> Add CD to collection. </toyml:caption>
<ev:listener event="onclick" observer="v1" handler="#addCD"/>
</toyml:button>
<toyml:button id="b2">
<toyml:caption> Delete CD from
collection. </toyml:caption>
<ev:listener event="onclick" observer="v1" handler="#delCD"/>
</toyml:button>
...
</toyml:collection>
...
<ev:listener event="focusIn" observer="m1"
handler="#displayCDDetails" phase="capture"/>
</toyml:music>
The add and delete buttons can be inserted at appropriate points in the host XML document. The example above shows the addition of these buttons to Christa Ludwig 's collection element. It is assumed that handlers that implement the appropriate actions are implemented via scripting or other means.
When the Music Inventory application is loaded in the XML browser, class Interpreter traverses the document tree and instantiates, for every event listener found, an EventTarget class whose target node is the node on which the listener has been declared, e.g., the <collection id="v1"> element. To each EventTarget instance, it instantiates and attaches an EventListener class which is wired appropriately with its associated handler. Since the phase of both listeners is not explicitly set, it defaults to target and bubble. Finally, the Interpreter registers the two listeners with the contained EventController instance at the target node <collection id="v1">.
When one of the buttons is clicked, for example button <button id="b1">, an onclick event is generated. Before the event propagates through the document tree, class EventController computes the path from the root to the target node on which the event was fired. Following the example above, the list of nodes thus generated will contain node <collection id="v1"> since it lies on the path from node <music id="m1"> to node <button id="b1">. This list is added to the onclick event. The event is then dispatched down the document tree.
Event dispatch starts by EventController propagating the event from the root to the target, updating the CurrentTarget node as the event moves along the computed path. Since there is no registered listener with phase=capture along this path for this event, there is no handler to invoke. Once the event reaches its target, i.e., <button id="b1">, the EventController searches for any listeners registered on that node itself. Again, following our example, none is registered, so there is no handler to invoke. Finally, the EventController begins propagating the event back up towards the root, this time updating the CurrentTarget node from the list of nodes (computed path) in reverse order. When the event reaches node <collection id="v1">), the listener registered on that node for the onclick event type gets activated, since that node has registered itself as an observer; this invokes handler addCD . The event continues bubbling up to the root, however since there are no more listeners for that event type on the path, no further handlers are executed.
To display a CD when it acquires focus, we add an event listener whose observer node is the root of the music collection, and set its phase to capture . The mechanism by which this listener is interpreted, registered, and activated mirrors that of the onclik event listeners described in details above. Note however that registering the listener on the root element itself and setting is phase to capture, enables centralized event handling; As focus changes from one CD to another, the focus event propagates through the root of the music colection and gets handled in the capture phase. Centralized event handling obviates the need to attach a separate view handler to each <cd> node.
In conclusion, DOM2 Events as exposed by module XML-Events provides a simple yet powerful authoring metaphor for creating and deploying semantically rich XML content. Events bring XML content to life; the ability to easily attach more functionality to the host XML browser, and expose this functionality to the hosted XML content turns the XML DOM into a powerful application deployment platform.
Earlier sections described event propagation in terms of user interaction events such as mouse motion and mouse clicks. Notice however, that the event model as defined by DOM2 allows handling of generic events; thus, user-generated and system-generated events can be handled in a consistent manner. Thus, an XML-browser capable of processing DOM2 events can react to both user and system events using the same mechanism. Further, module XML-Events allows the XML author markup-level access to this event processing mechanism, thereby enabling the authoring of declarative behaviors for responding to generic events. This ability to react to system-generated events can be leveraged in integrating different plug-ins into an XML browser. Thus, as XML-browsers gain more and more functionality, new content that takes advantage of this functionality can be authored using declarative XML markup.
As an example, consider adding location-awareness to an XML browser. Location information arrives at the XML browser through a Global Positioning System (GPS) module. An XML application wishing to react to updates from the GPS module need only register an event listener for the correct event type. Integrating module GPS into the XML browser requires turning location updates from the GPS module into the appropriate event structures . XML content that wishes to react to location updates need only provide event listeners and handlers for the events generated by module GPS. The wiring-up of the GPS events to the interactive behavior specified by the XML author is handled by the event dispatch loop described above.
Later, a time module that generates events based on time of day might be added to the same XML browser. Finally, the simple music collection application may become time and location aware by attaching event listeners for time and location updates, and by presenting music choices based on the user's current location and time.
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://examples.com/2001/toyml"
xmlns:toyml="http://examples.com/2001/toyml">
<xsd:annotation>
<xsd:documentation xml:lang="en">
ToyML --- a language for encoding music collections.
</xsd:documentation>
</xsd:annotation>
<xsd:element name="music" type="MusicType"/>
<xsd:complexType name="MusicType">
<xsd:sequence>
<xsd:element name="genre" type="MusicGenre">
<xsd:attribute name="id" type="xsd:ID" use="optional"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="MusicGenre">
<xsd:sequence>
<xsd:element name="collection" type="MusicCollection">
<xsd:attribute name="id" type="xsd:ID" use="optional"/>
<xsd:attribute name="name" type="xsd:genreEnum"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="MusicCollection">
<xsd:sequence>
<xsd:element name="cd" type="xsd:string">
<xsd:attribute name="id" type="xsd:ID" use="optional"/>
<xsd:attribute name="type" type="xsd:CollectEnum"/>
<xsd:attribute name="artist" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="GenreEnum">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="classical"/>
<xsd:enumeration value="jazz"/>
<xsd:enumeration value="pop"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="CollectEnum">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="vocal"/>
<xsd:enumeration value="instrumental"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
XML Events - An events syntax for XML, Steven Pemberton, T. V. Raman and Shane P McCarron, 2001. W3C Working Draft available at: http://www.w3.org/TR/xhtml-events.
Document Object Model (DOM) Level 2 Events Specification, Tom Pixley, 2000. W3C Recommendation available at: http://www.w3.org/TR/DOM-Level-2-Events/.
Extensible Markup Language (XML) 1.0 (Second Edition) , Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, 2000. W3C Recommendation: available at: http://www.w3.org/TR/REC-xml
XForms 1.0 , Micah Dubinko, Josef Dietl, Roland Merrick, Dave Raggett, T. V. Raman, Linda Bucsay Welsh 2001