DOM Events, XForms relevance, SMIL timelines and more

Last week, Steven and me did some brainstorming on the various ways  
that an object can "start doing its thing" in different XML languages.  
Here's what I remember from that conversation (of course I lost my  
notes:-), Steven, please fill in. And, others: please do so as well.  
This mail has become a bit of a braindump/rant (especially towards the  
end:-) but my hope is that it can spark some discussion and eventually  
lead to something a bit more coherent:-)

I'm specifically using the term "start doing its thing", because terms  
like activation already have a well-defined meaning in some contexts  
(as we noticed at the last teleconf). I'll abbreviate it to SDIT from  
now on. My hope is that we can come up with some method to either  
unify these concepts or (more probably) bridge them (i.e. have one  
SDIT method trigger another). This would enable more integration of  
different technologies, allowing the technologies to be used together  
to create richer webapps with less effort.

SDIT somehow implies a transition, from a state "not doing its thing"  
to a state "doing its thing". For some cases a DIT/NDIT model is  
better, for others the SDIT model. But I would like to ignore the  
distinction for now.

XForms has three different methods of SDIT:
1. Controls may become visible or invisible based on their  
"relevance" (formal XForms term). The relevance is actually an  
attribute of items in the model, but controls bound to these model  
items pick up this relevance. For an example of relevance, think of an  
address book entry format that has a "department" field, and a "is a  
home address" boolean. "department" is relevant if and only if "home  
address" is false. An item which is not relevant may be completely  
hidden, or shown greyed-out, but the important thing is that for most  
purposes it is dead as a doornail: it's not updated, it doesn't react  
to DOM events, doesn't emit events, etc.

2. Actions, such as "send", start doing their thing based on an event.  
Usually DOMActivate, but this can be a different event too. When the  
event comes in the send starts transmitting data to the server, etc.  
<action> is a bit funny, as it is (I think) the only action with  
something resembling a timeline: it causes its children to start doing  
their thing in strict order.

3. There's a slightly odd case: the XForms <switch> element, which  
allows for things like tabbed dialogs or wizards (if I understand  
correctly). These have their own mechanism for determining which  
alternative is visible. I think it is so targeted at a specific use  
that we should ignore it.

SMIL, on the other hand, has a timeline-based method of making the  
various objects do their thing. Initially, a SMIL player will  
construct as much of the time graph as it can deterministically  
determine. At the very least this will include the start time of the  
<body>, which is "right away". It will definitely not include any  
begin or end times determined by events, or end times of media of  
unspecified duration (which includes live streams, but also non-live  
continuous media for which it would be too expensive to get their  
duration beforehand), and everything for which the begin or end  
depends on one of the previous 2 cases. There's a few more cases  
(indefinite begin, children of <excl> elements), but this is the  
general picture. After the initial timegraph has been constructed it  
starts playing back, and things times that were previously undefined  
are now suddenly becoming defined (because a continuous media item  
ends, or an event happens and the receiving object is waiting for it,  
etc). This allows the scheduler to construct a few more bits and  
pieces of the timegraph.

If we look at SMIL from the micro-level, i.e. "how a single element  
sees the world", what we (Steven, actually:-) noticed is that there's  
a parallel to XForms relevance. The details of an elements' lifecycle  
can be found at < 
 >, but we can map it to relevance by saying:

1. An element is in SMIL reset state (which maps to XForms non- 
relevance) unless all of its ancestors are active. (there's also a few  
more details for <seq> children, but let's ignore that for now).

2. An element goes through its other states (waiting for being  
conditions, playing, pausing at the end, dead) maps to XForms  
relevance. Only in these states does it listen for begin and end  
events, emits events and (sometimes) plays, repeats, etc.

[Sideline: I think I now understand why in the SYMM group we've had so  
much trouble with DOM events and all their bubbling and capture and  
such, and why the DOM Events people had so much trouble with us:  
because at the time we had no clear concept of relevance. The same may  
be true as well for accessKey in its various incarnations: the other  
thing we never managed to get right/communicate correctly]

Ideally, we would also be able to integrate other ways in which web  
documents have state transitions. HTML/CSS "display" comes to mind,  
and maybe also "visibility". Also, I think SCXML and VoiceXML have an  
execution model,  so there should hopefully also be some way to let  
their SDIT concepts to the ones sketched here. But: I know very little  
about these. Same for XBL: I think it must have some sort of SDIT  
concept, but I don't know enough about it.

The most difficult player, but possibly the most interesting one from  
a practical point of view, is probably JavaScript, because of its  
procedural nature. A piece of JavaScript makes another bit of  
JavaScript SDIT by calling it. It does so to non-JavaScript objects by  
calling their DOM methods (or adding/removing them altogether from the  
DOM tree). Non-JavaScript objects can have JavaScript code SDIT   
either through onclick="..." attributes or DOM event handlers.
Jack Jansen, <>,
If I can't dance I don't want to be part of your revolution -- Emma  

Received on Monday, 16 February 2009 22:24:53 UTC