Hypertext Coordination Group Backplane Meeting (Amsterdam) Day 2 November 21, 2006

* Present

Jack Jansen, CWI (SYMM)
Scott McGlashan, HP (Voice)
Rafah Hosn, IBM (Voice)
Charlie Wiecha, IBM (co-chair, Forms)
Henry Thompson, W3C/University of Edinburgh (TAG)
Rhys Lewis, Volantis (Voice)
Chris Lilley, W3C (via IRC, CDF, HCG, SVG)
Dave Raggett, Volantis (Voice)
Leigh Klotz, Xerox (minutes, Forms)
Steven Pemberton, W3C/CWI (co-chair, HTML, Forms)

* Agenda


* Issues and Categories

Steven Pemberton: What are the important things that we want to talk about today? It seems to me that eventing is something that arose time and again. What was written on the board?
Henry Thompson: Same site business, external dependencies, and ... let me check my notes.
Charlie Wiecha: Submission, both rethinking XMLHTTP and a declarative level. These two communities need urgently to start talking. The other one is a cool discussion around voice and SMIL and the data model
Scott McGlashan: Pluggability.
Charlie Wiecha: There's a set of communities to get together to explore. The XForms guys can get together to talk about the transaction model, and then feedback to the XForms guys about profiling. Not answering the questions here but figuring out a lightweight process.
Scott McGlashan: The pros and cons of ECMAScript, etc. A shared understanding is useful.
Charlie Wiecha: We have communities now wrestling with practical issues and need to connect them. We want to avoid the intergalactic 30-year timeframe issues. My third issue is getting towards the loosely-coupled interaction model; a more common approach to MVC architectures. We've championed that in XForms but we can pull model/view/binding/behavior out of the XForms namespace. That gets us away from the mashup into the hookup world.
Steven Pemberton: A good thing would be if every attribute allowed curly brackets to get
Rhys Lewis: Attribute value templates.
Steven Pemberton: It wouldn't be namespaced but they would reserve curly brackets.
Rhys Lewis: Yes, that's in DI spec. It says the host language must.

Steven Pemberton: The next thing I would queue up is the model for DI. XForms and VoiceXML use similar models, but what about DI.
Scott McGlashan: We borrowed the model from XForms.
Steven Pemberton: Then I'd like to call that convergence for DI, Voice Browser, XForms, and SMIL. That would encourage other groups.

Charlie Wiecha: The Russian Doll model, as in model-to-model composition and recursive operations such as XAC that Rafah showed.
Scott McGlashan: It's a constraint on the backplane, not necessarily a feature.

Henry Thompson: The hardest agenda item is then tactics. If we go away for three years and have the best thing, then it would be 24 months late and nobody would be interested.
Charlie Wiecha: That's why I think bottom-up for model and submission would be practical.
Scott McGlashan: And success would be coordination. I don't want to produce a mega-document
Charlie Wiecha: Been there, done that. Tactics isn't easy because people don't want yet another weekly call.

Rhys Lewis: I feel obliged, representing the accessibility community, to say we talked about users preferences and dynamics of delivery context.
Steven Pemberton: In a sense that's related to SMIL; it's different from accessibility but it's the same area.

* Tactics

Charlie Wiecha: Before we get into specifics, Henry do you want to talk about tactics?
Henry Thompson: I'm on the outside here, but we could go either way. We often do worst with getting out in front and best with minimal packaging. We might get people to gather, but we might also have the better mousetrap problem. So the question is how we get buy-in from the people?
Rafah Hosn: We have the people at the table.
Steven Pemberton: Henry means the browser manufacturers.
Henry Thompson: Tell me that they're now important or how you're going to get them on board.
Rhys Lewis: XForms has shown that you can implement it today in server side or client scripted architectures on the device.
Henry Thompson: So there is a twin-track story.
Scott McGlashan: The author doesn't care what's in the JavaScript as long as their markup will continue to work.
Henry Thompson: It changes the cost of entry, downloading files and serving them and keeping them updated vs. you just have to know these URLs. That's a significant difference and affects uptake. So the best we can hope for is a twin-strike strategy. At the very least you have have a twin-track story and the overall architecture has to support graceful evolution if it ever becomes possible.

Steven Pemberton: I tend to agree with Rhys but I know a number of people who believe that if it isn't in the browser, it doesn't exist. The browser manufacturers are in a niche. There's not much reason to be better than the others. With XForms there has been strong uptake because there are a number of solutions, including server-side transformation, using JavaScript as the assembly-language of the web. I'm optimistic because I've seen XSLT and XPath adopted over objections of browser manufacturers. The browser manufacturers are not the leading edge, nor should they be. You've got to produce the technology, then get some sort of uptake, and then the browser manufacturers will follow.
Henry Thompson: Yes, but... then you will "just" be competing with all the other JavaScript toolkits that are out there, then you are not taking advantage of the W3C's position. You are then competing with DOJO and the others. The advantage of the twin-track story is that we have a plan for taking the high ground. The browser vendors are perfectly understandably conservative, especially around as you said yesterday, "the security model."
Charlie Wiecha: You said we do well when we standardize things and less well when we get way out ahead.
Henry Thompson: Those are generalizations; SVG and XForms are examples and exceptions.
Charlie Wiecha: The data model, for example, is not ahead, but is boiling down differences in the approaches we already have. So a good chunk of the backplane is not blue-sky but is getting our house in order, consolidation and collaboration instead of cooking up blue-sky stuff. The paper currently reads as blue-sky but needs to show it is learning about our existing experience and is pragmatic.
Henry Thompson: Makes sense to me.

Rafah Hosn: In the Voice Browser working group, we are a bit independent of the desktop browsers, and we have an opportunity in VoiceXML 3.0 to clean up and allow things such as hookups and Russian Doll models. Even without Mozilla and IE here, we are able to build our voice browsers from scratch.
Charlie Wiecha: There aren't that many voice browser vendors any more, are there?
Scott McGlashan: There are ten to twenty.
Dave Raggett: That's a lot.
Henry Thompson: The claim is that mobile vendors are going to be leading, and the PC browsers are going to be following the new dominant browsers and provide features that people demand from mobile browsers.
Rhys Lewis: That's the one place where browser vendors make money because they sell it to mobile vendors. As Charlie was saying, these applications are not blue sky; we're delivering them now on mobile browsers. If we don't make this rational, it will be on Flash-light.
Charlie Wiecha: That may be a good market for voice as well.

Steven Pemberton: Our conclusion is that it is not problematic to try to do some of this stuff even though the browser manufacturers are not necessarily on board.
Charlie Wiecha: We are already doing it, and we are just collaborating on consolidation. We need to reinforce the pragmatic nature.
Rhys Lewis: We have a charter and we need to be doing the right things to advance this work.
Charlie Wiecha: Yes, and some of this work may go into the XForms charter.

Charlie Wiecha: Shall we continue?
Henry Thompson: Or leave it to one side, drill down, and come back to it?
Steven Pemberton: We need to figure out how to engage the non-declarative parts of W3C.
Dave Raggett: I also see the value of non-declarative work.
Charlie Wiecha: I'm not polarized, but I want to give people routes to adoption.
Dave Raggett: Scripts...
Steven Pemberton: How do we make sure the WAF-WG is on-board.

Jack Jansen: [arrives]

* Same-site

Charlie Wiecha: So shall we take the order on the board?
Steven Pemberton: The one I know the least about is the same-site problem.
Charlie Wiecha: I'd like to push back a little on that one and say that we want to build an XForms, an HTML, a Voice XML application, and not focus on multi-site mashups. Instead, look at the common artifacts of submission, model, etc. So I'd like to get going there.
Rafah Hosn: I don't think we can solve the issue here.
Rhys Lewis: There is a new security group for the web.
Scott McGlashan: Are they doing same-site?
Rhys Lewis: They were on the last HCG call but I haven't read their deliverables. Clearly these issues are amenable to solution; it doesn't sound tactical.
Charlie Wiecha: Let's not raise red-flag issues that we don't need to for a year or two and focus on impact.
Steven Pemberton: I don't know to solve it; it's a total pain.
Rhys Lewis: It seems an important question but I don't think we need to solve it for the universe.
Leigh Klotz: Just don't touch the spinning gold rings and you'll be fine.
Scott McGlashan: And mobile browsers?
Rhys Lewis: There are some bugs that they don't obey it, but in the network there are other security features. They still manage to deliver applications.
Rafah Hosn: There are three groups doing security in the W3C.
Henry Thompson: None are doing the same-site policy. If memory serves, Microsoft implemented it and everybody followed.
Jack Jansen: So you want your site to sign the library. It just happens to be the way that it's implemented now for the same site; you just have an MD5SUM.
Leigh Klotz: You just described two years of meetings.
Rhys Lewis: In UWA we're not proposing to do anything immediate.

* Events

Rhys Lewis: It seems to me that events are core to this; a lot of work has been done already. Getting some of that work finished would be tactical.
Steven Pemberton: The accesskey replacement is a part of that; do you agree?
Rhys Lewis: I assumptively described that?
Steven Pemberton: Shall I add that to this list?
Rhys Lewis: Yes.
Steven Pemberton: Events/access(key)
Rhys Lewis: XML Events 2 is clearly a core part of coming to consensus about the event model. Talking with Dave, I wanted to discuss SCXML and DOM events.
Rafah Hosn: The event propagation is different in SCXML. It's can't have events bubbling up and down. There's no point in events going up and down a tree.
Charlie Wiecha: It's a way of implementing an action handler. It's a contained unit of behavior.
Scott McGlashan: It has an internal structure though. It's different from the DOM.
Rhys Lewis: There's the representation of the event, and there's the propagation. Can we view one as a specialization of the other, or both as aspects of a more fundamental model?
Rhys Lewis: There's no semantic similarity of the event propagation. For the representation, nothing in SCXML prevents you from taking a transition on a DOM event, such as xforms-value-changed. SCXML just tells you what state you'll end up in when you get the event.
Henry Thompson: It's the vocabulary for describing what to do with the events.
Charlie Wiecha: That's why it's a Handler, not an event. The bubbling doesn't happen in the state machine. On the other hand you might want to raise events and have them bubble out.
Rafah Hosn: You can send events out.
Charlie Wiecha: I mean something different; on the outside you can listen for the event.
Rafah Hosn: As you enter the state, fire the event on yourself and it will.
Charlie Wiecha: So make it easier for the author and make the engine do that for you.
Rhys Lewis: And you can then build a debugger.
Charlie Wiecha: ...
Scott McGlashan: So is there a general model of event propagation and the difference is the structure under which it is triggered? Is there value there?
Charlie Wiecha: In using the IDL for DOM Events?
Scott McGlashan: In CCXML we don't use bubble. The events do percolate up and look for something that is prepared to catch them; otherwise they disappear. They percolate. That's a feature in common. Is it sufficient to justify? I'm not sure.
Rafah Hosn: For VoiceXML, it's a bit different from SCXML. You can envision events propagating with capture and bubble. In SCXML 2.1 they just don't bubble. In SCXML there's no semantics; the events don't propagate. You compute a set of active transitions and set of target states and the event takes you from here to here.
Rhys Lewis: There's no reason to force them if they're fundamentally different.
Rafah Hosn: Processing events in an SCXML state machine
Rhys Lewis: And generating
Rafah Hosn: is different from propagating events within that state machine.
Rafah Hosn: SCXML is to the mashup a handler; internally it does its own thing, and they may raise DOM events.

Jack Jansen: We found that the bubble and capture model is perfect for static documents, with lexical closure. With SMIL, we made it fit, but we had to push hard because lexical enclosure isn't all that important: temporal scope is what it's about. Is that true for you as well?
Rafah Hosn: Temporal is important in a specific case; you can have timeout events.
Jack Jansen: I mean active or not active.
Rafah Hosn: Yes,
Jack Jansen: Internal state
Steven Pemberton: In XForms, whole chunks of the DOM tree can be made irrelevant, and we have to switch event catching off and on for them. Scott; That's very close to SXML.
Jack Jansen: You have a sequence of images and the fourth image has an event. First it goes into scope, then the sequence get started and stop. By the time the fourth get started it opens up its event listening.
Steven Pemberton: That's exactly the same.
Jack Jansen: It's just lost if the event is there first.
Rafah Hosn: It's the same. You take the internal events first. We have an extra step of computing internal events as you transition from one state to another; once we do that, we are done with one step of the algorithm and then we open it up to external events.
Jack Jansen: So we execute the time graph and then you're open to events.
Steven Pemberton: The same as relevant in XForms.
Rafah Hosn: Do you stop propagation?
Steven Pemberton: No we stop handlers.
Rafah Hosn: Do you skip over a portion of the tree?
Steven Pemberton: It's not possible to have a relevant child and a non-relevant parent.
Rhys Lewis: It sounds like we have identified something in addition to events.
Jack Jansen: If SMIL had that it would avoid a large amount of prose.

Resolution 2006-11-21.1: In addition to events, the backplane needs some form of relevance.

Rafah Hosn: Is this a requirement for DOM3?
Steven Pemberton: We identified three markup languages that we all thought had a unique requirement.
Scott McGlashan: We compared the VoiceXML eventing model with DOM3 and found it could be explained. We can break it down into event queues, relevance, percolation. Even if SCXML doesn't use those terms, it is worth investigating to see if it can be.
Steven Pemberton: So owns DOM3 events?
Dave Raggett: WEB API. They wanted no new features. But it's not high priority. They had a spec out recently. There were some new events proposed, but they were cut.

Charlie Wiecha: We talked about the debugger, listening outside the state machine. But you could also listen inside the state machine for events, for transitions, and a state entry event bubbles up and then dispatch events somewhere else. It just gives you more visibility to the operation of the tree.
Rafah Hosn: It doesn't change the semantic model; it's just sugar on top.
Charlie Wiecha: It makes it easier to see what happens inside. State entry, state exit, transition, traversal. If those are dispatched internally, as with xforms-value-changed, recalculate. So if you know in some parallel region the transition has happened, you can then dispatch something else.
Rafah Hosn: We had state.entry and state.done but we took them out, to simplify implementation, and because the author can send the events anyway. So I don't think a state machine event propagation model can map to an hierarchical model. I don't think there is a need to do it. I'd like to have events going up and down a tree model. That transition semantic is available to the author.
Rhys Lewis: Are there things in SCXML that could beneficially move out?
Scott McGlashan: Things like explicit queues; internal and external eventing queues.
Rhys Lewis: Preventing events from doing things to parts of the document under certain circumstances, which SCXML has and DOM events could learn. I heard the SMIL / XForms / relevance idea.
Scott McGlashan: Depending on which state is active, that affects what events can go on.
Charlie Wiecha: The machine as a whole gets the event; the states that are active
Scott McGlashan: The relevant ones
Charlie Wiecha: get the events. But you don't have any other bubble or capture.
Scott McGlashan: I suppose one difference is the exclusive capture; only one transition handler captures an event, a feature shared with VoiceXML.
Rafah Hosn: There's a new feature in VoiceXML for parallel.
Rhys Lewis: There may be two things but there are two event models.

Charlie Wiecha: Are there other event models?
Dave Raggett: Queuing or delay of events for grouping, and network efficiency.
Scott McGlashan: Delaying with CCXML and VoiceXML is for sending. You can set up a timer.
Leigh Klotz: It's called Nageling in TCP.
Rhys Lewis: It's a reasonable algorithm.
Charlie Wiecha: Scott is saying delaying; Dave is saying queuing for network efficiency.
Rafah Hosn: Dave, you'd like to see this at the author level?
Dave Raggett: To be honest I don't understand the requirements, but if you are synchronizing two DOMs, some events aren't appropriate to send and others can be batched.
Rafah Hosn: We investigated that question at IBM with the multi-modal framework and we decided to do that at the implementation level and automatically discover whether to batch.
Scott McGlashan: So you had a time window, same target?
Rafah Hosn: Yes.
Dave Raggett: So some events are time critical and some aren't?
Scott McGlashan: Debugging, low priority.
Leigh Klotz: It's like TCP with urgent data, and more recently QoS.
Dave Raggett: Don't muddy the layers with application events; you need to know the data model for them if you want to serialize them, such as XML. There's metadata associated with the event such as relevance, data model, timeliness etc.
Jack Jansen: So you have a place to hook in
Dave Raggett: Rafah's quite right; you don't want to burden the author. But you don't want to have a fixed set of events either.
Jack Jansen: So in a distributed program if you send events on every action
Dave Raggett: Some events are local only
Jack Jansen: Maybe the author has to explicitly ask for events to be passed over the wire.
Dave Raggett: The subscribe/notify model isn't always appropriate. Servers listen for others to send requests.
Jack Jansen: Aren't you misusing events for something else?
Dave Raggett: Messaging is a tool. What is the role of metadata in these models?
Jack Jansen: You're depending on a response and those are marked in CCXML/SCXML.
Charlie Wiecha: These are still future-looking. Steven what is the status of XML Events 2. Maybe a concrete action item for Voice and SXML is to look at XML Events 2 for the base functionality?
Rafah Hosn: We looked at DOM Events 3. It sounds like requirements there are harder.
Scott McGlashan: We could influence that.
Dave Raggett: If the HCG came up with some kind of story about events, that would have a major impact on DOM 3 Events going forward as is or listening to input. What do we want to say?
Rhys Lewis: It could be a set of requirements against DOM 3 events and XML Events.
Dave Raggett: So is there a problem moving it forward, looking backward at HTML?
Henry Thompson: I'm of two minds. It was clear that there is no single point at which anyone can go to get the story about events at W3C. It would take ages, but is it a waste of time to identify a locus of creation for a summary document (pointers, status, responsibility)? Maybe 4 people in a month, or it may take 3 coordination groups 6 months to agree. What's your sense?
Scott McGlashan: It's something we've been doing in VoiceXML. We'd like to influence DOM 3 if there are areas of overlap.
Henry Thompson: So maybe keep XML Events 2 from being approved before this is done? That's maybe too high a bar but an interesting thought experiment.
Rafah Hosn: We've figured out about DOM 3 and how it could be used; we'd like to share those documents and have issued proposals, informally.
Scott McGlashan: That would be a great start.
Jack Jansen: I haven't looked at the events in XForms but would like to.
Rafah Hosn: We haven't looked at XML Events 2 but would like to.
Jack Jansen: But XML events aren't useful to us. You say begin=othernodes.repeat-event. That integrates with the rest of the timing model. I don't think there is any value in trying to put XML events on that.
Rafah Hosn: Then should we start with DOM 3 events?
Henry Thompson: Then at the non-tech plenary we could have an Event Summit.
Jack Jansen: We're going to be in Rio.
Steven Pemberton: Lots of groups aren't there.
Henry Thompson: Then, there ought to be an event summit and all the groups that are stakeholders should send representatives.
Steven Pemberton: This meeting came out of an original suggestion that we have an events workshop. So this is it. We could organize a public workshop.
Henry Thompson: Are all the event stakeholders in W3C represented here?
Scott McGlashan: Start local
Rafah Hosn: Grow regionally
Henry Thompson: It can be done right away but increases the number of NIH responses.
Charlie Wiecha: We hoped that WAF and WEB-API would come. We need to discuss a process for bringing them in.
Henry Thompson: Either do what DOM3 events does or get them involved.
Dave Raggett: The spec has been fast-tracked but it doesn't represent the requirements of the groups.
Henry Thompson: How do we raise the DOM3 events coordination issue?
Steven Pemberton: That's HCG
Henry Thompson: They are the ones who asked for the telephone connection; a couple were on yesterday but none today.
Dave Raggett: It seems that coming out of this meeting, we have a statement of the nature of the problem for HCG. Individual working groups should provide their feedback on the DOM3 spec, and have email discussions about next steps, such as a workshop. Short term steps should come from the working groups.
Steven Pemberton: Here is the latest editor's draft of XML Events 2. http://www.w3.org/MarkUp/Group/2006/WD-xml-events-20061108/ We can push it out if necessary.

* Break

* Events Continued

Steven Pemberton: Here is DOM 3 events: http://www.w3.org/TR/DOM-Level-3-Events/
Dave Raggett: WebAPI charter has DOM3 events in Q1 2006, but it has still to reach LCWD status, current draft 13 April 2006. So we need Dean's input on what the WG really thinks the timeline is.
Chris Lilley: [via IRC] http://www.w3.org/2006/webapi/group/timeline linked from http://www.w3.org/2006/webapi/group/timeline

Charlie Wiecha: Any shorter-term action items related to events?
Steven Pemberton: I'd like to push forward intent-based abstract events for Accessibility and DI.
Rhys Lewis: Where do we think that lives?
Steven Pemberton: There is a note produced by Raman and myself, linked from the agenda. http://www.w3.org/MarkUp/Forms/Group/Drafts/1.1/intent-based-events.html
Rhys Lewis: Could that live within UWA? I'm not volunteering.

* Navigation

Steven Pemberton: Another thing is navigation in a compound document. We ought to add that to the list. Different markup languages say different things about how to move node to node. HTML has navindex, next-focus, previous-focus. If you have different versions of those in one document, that's hard to navigate.
Jack Jansen: We want to do that in a temporal way. In XForms, the irrelevant bits. In Voice XML?
Charlie Wiecha: There's no display on the screen but you can take input. It's not tabbing.
Jack Jansen: We picked up tabindex but it doesn't work.
Steven Pemberton: Tabindex doesn't work because you have to renumber everything.
Dave Raggett: In IE and Mozilla tabindex=0 keeps it, and -1 removes it. If you add a click handler to a list item, not all browsers you tab sequence in. So there are practical issues for accessibility to be fixed; it just needs clarifying. Al Gilman's points were good: letting a script find out where you are and what you can do. Most cases these involve hierarchical navigation.
Scott McGlashan: And in an abstract compound document?
Dave Raggett: it there a notion of focus? Verbs or actions? The conceptual model is there.
Scott McGlashan: You can use input from the user.
Dave Raggett: tabindex isn't the right model; there are speech gestures, for example.
Jack Jansen: Now that I think it, we have that, but it's not explicit. Abstractly, yes, it's an interesting way to think of it. Going in and out of scope, what is reactive at a given point in time, that is unstructured. It's not as if you can deduce that from the structure of the document.
Scott McGlashan: In VoiceXML you can install global handlers, so we are not affected by going in and out of focus.
Jack Jansen: In SMIL you can be in multiple places. You can have two presentations going side-by-side.
Rhys Lewis: It's the union. It's still a computable set.
Dave Raggett: Then accessibility is a useful angle; if they can't see the presentation, what can they do?
Jack Jansen: We come up with a reasonable tab order and you can tab through that, from active element to active element. You could be at a field and about to type and the field goes out of scope.
Leigh Klotz: Is your concern that you can't statically analyze the document?
Jack Jansen: We can't, but not a concern, no.
Dave Raggett: I can imaging going backwards in time with an accessibility agent.
Jack Jansen: We can say that once you hit "tab", time stops.

Charlie Wiecha: Is there a navigation document?
Steven Pemberton: There is a bit about navigation in the intent-based events. CDF is not represented here but it is an ideal topic for them to own.
Rafah Hosn: We can always assign them meetings.
Henry Thompson: If you don't come to the meetings you get action items.
Charlie Wiecha: What is the status of intent-base events?
Steven Pemberton: It's a note.
Rhys Lewis: It's for things with well-defined names.

Jack Jansen: Steven, do you own that intent-based stuff?
Steven Pemberton: By default because we produced it.
Jack Jansen: People have been asking us for real-estate navigation. Not through document order, but up-down-left-right. That would be very nice to have. The implementation would be really difficult. But if you're standardizing a set of names, it would be nice to have placeholders...
Steven Pemberton: For presentation-based navigation.
Jack Jansen: If you are watching a presentation, you want the field above the one where I am now.
Rhys Lewis: So these are non-DOM3 events.
Charlie Wiecha: It just an "ontology." There are the categories in the document. CDF would seem an idea place to map these onto the individual events from the namespaces, the profile issues.
Rhys Lewis: It sounds like there's work to do to enumerate the events.
Charlie Wiecha: And to name them.
Steven Pemberton: If you look in DOM 3 events, you see DOMFocusIn, but also click, mouseout, nodeinserted. A bit of a mish-mash really.
Dave Raggett: It doesn't seem to cover the space, really.
Rhys Lewis: How important are intent-based events for the vision of the UWA?
Dave Raggett: Once you define the event data models, the event metadata, that's easy. If you want to define without regard to a particular presentation, then it's important.
Rhys Lewis: It sounds like this lets you create application events.
Dave Raggett: These don't look like application events to me.
Rhys Lewis: This is in the lingua franca for intent-based events. Is this the right way to provide for application events? You have to define data models, behavior, serialization for this lot. So then there is the extensibility model. Is that how you define application events are transported over the same mechanism?
Dave Raggett: These seem more about actions than events. For setfocus, you want to invoke that action.
Steven Pemberton: Right. Click now causes all sorts things of things to happen, but when listening on a link, you just want to know it has been activated.
Dave Raggett: One is action that causes things to happen, and the other is what has happened.
Steven Pemberton: Yes, both.
Dave Raggett: There is room for both. Then there is "Where Am I?" which is neither an action nor a notification. It's a bit confusing.
Rhys Lewis: There's more than one thing in here.
Dave Raggett: Undo/cut/copy/paste may be related to work in Web API on drag and drop; so they may be interested.
Steven Pemberton: Sure.
Charlie Wiecha: So a followup may be for you guys to talk to Kevin Kelley and see if there is room in your new charter or theirs?
Rhys Lewis: We have specific things. One of them is Rex. Another is application-level eventing. We would like a single if we can manage it.
Dave Raggett: One plan is to cover this in the modeling workshop in the Spring; how do you describe web applications at a device-independent level?
Rhys Lewis: Maybe Russian doll nested components?
Steven Pemberton: Or composition and late-binding approaches.
Dave Raggett: Or goal-based descriptions.
Rhys Lewis: We should do something near this space in UWA. I think we are in a position to say something about the onotologies of gesture and actions. Clearly the low level is DOM3; we know the problems with DOM3. These things are at a higher level and might be responses to DOM3 events.
Dave Raggett: We could put wording in the charter for "intent-based events," involving actions, notifications and inspections, and involving coordination with that list. In terms of the activations in the charter we should look at that separately.
Rhys Lewis: I think that addresses the accesskey issue; if we do it in the DOM3 space, as a strawman, does that solve the issue with accesskey? If we pass the requirements from at least XForms and SMIL on DOM3 events, and say we will address the accesskey issue through UWA, does that cover everything we need to do on eventing?
Steven Pemberton: Er, I think so. The only thing that is left over is maybe event context, the value that is carried around. We have an XPath function that reveals the details of the event, which you can use in a variety of ways.
Rhys Lewis: Is that a natural consequence of it being XML Events?
Steven Pemberton: No.
Leigh Klotz: Isn't the function defined in IDL?
Rhys Lewis: We could have a delivery-context changed event?
Rafah Hosn: We have that.
Steven Pemberton: So to answer the question, that covers is just about.
Dave Raggett: The work Rex requires some data model for events; IDL isn't quite enough. It doesn't describe all the properties. If there's work in Rex it means looking at the list of events. Quick aside, Rex v2 included all the events. We wanted to extend the RNG schema, and Chris wanted to extend it with SVG events, so we needed an modular way to extend the set of events, the ontology.
Rhys Lewis: You could discuss it with XML Schema?
Dave Raggett: Robin Berjon had said it was far from ideal.
Henry Thompson: I'd like to talk to you about that.
Dave Raggett: I did ask Michael and he didn't answer.
Henry Thompson: ...
Dave Raggett: In Rex V2 done in UWA, for the formalization of DOM 3 events, it would seem to use XML Schema but...
Henry Thompson: Can you give me an example.

Action 2006-11-21.1: Dave Raggett to send details of issues with describing Rex V2 event extensibility in XML Schema to Henry S. Thompson.

Rhys Lewis: So for HTML WG you would be happy to see that work proceed in a different form?
Steven Pemberton: As long as the parties who are involved continue.
Dave Raggett: Maybe a task force.
Steven Pemberton: I think that is the best way to go, so you can be sure everyone is thinking and discussing.
Dave Raggett: And the patent policy will be the same as HTML WG.
Rhys Lewis: ...

Charlie Wiecha: We also had a pair of things to do:

Action 2006-11-21.2: Each group to look at DOM 3 and XML Events 2 and report back to HCG.

Charlie Wiecha: I'm not a member of the HCG.
Henry Thompson: Insofar as Charlie or I wants to continue, the HCG is not the right vehicle.
Charlie Wiecha: We should have some recommendation for how to do that.

* Break

* Submission

Charlie Wiecha: So the idea that is bubbling up seems to be that we identify areas for cross-WG task forces. Eventing is one, and it seems like submission is another. There are two camps; one is markup, and the other is the Web API imperative. On markup we can look at Voice, SMIL, XHTML, and SMIL. In SCXML is there send?
Scott McGlashan: You can send. But in VoiceXML send without page transition.
Charlie Wiecha: So we can look for a common markup approach, with common events. And then figure out how that gets reflected at the script level at the Web API. That seems narrowly scoped and well defined and would have a big impact.
Scott McGlashan: So you could allow flexibility with different target types and different protocols as we have done with CCXML. We can use SIP, any protocol. We may want to scope it.
Charlie Wiecha: So unify the the forks
Rafah Hosn: invoke
Charlie Wiecha: with other submissions?
Scott McGlashan: They're all generic; so you could say a SIP or n HTTP send. You're using some transport protocol.
Steven Pemberton: It's URL-based.
Scott McGlashan: We've got a target type. It indicates which underlying transmission engine you want to use.
Leigh Klotz: You don't get that from the URI?
Rafah Hosn: The send is general; you can send an event to a place within the document; you specify an id.
Leigh Klotz: That's a relative URI.
Rafah Hosn: And a web service.
Leigh Klotz: That's URI.
Leigh Klotz: We have a table in XForms that takes in the action (URI) and the method and defaults the rest.
Rafah Hosn: We couldn't make that table.
Steven Pemberton: We want to decouple it all in XForms.
Scott McGlashan: We have a hint mechanism, an escape hatch that lets you specify an ECMAScript object that lets the IO processor interpret. It can specify TCP timeouts, for example.
Jack Jansen: We have a param child element and let renderers use it. We haven't looked at submission and would like to pick up what xforms does, and possible use param to extend it.
Scott McGlashan: Submit is a document transmission. We want to move to send without transition.
Charlie Wiecha: And you want to do that with different elements?
Scott McGlashan: Yes, either separate or a variation.
Leigh Klotz: On XForms we just use an attribute that says to replace all or just instance.
Jack Jansen: Is everybody doing submissions procedurally? I'd like to do it declaratively, whenever this and that happens.
Scott McGlashan: It's declarative markup.
Steven Pemberton: A number of submission elements give the details; then a certain something causes it to happen. A trigger element that someone clicks on.
Leigh Klotz: It's all event based for us.
Scott McGlashan: We should clearly get together.
Rhys Lewis: We use XForms and we're still in the same ballpark.
Rafah Hosn: It's nice to have just a parameter; it's easier than two elements.
Charlie Wiecha: You have a place in the model, the submission, that has all the info.
Scott McGlashan: We put all the details in the send. There are a lot of parameters.
Steven Pemberton: Web services has a lot of parameters...
Rafah Hosn: We opted not to specify that in SCXML. You have to specify it in a vendor specification.
Leigh Klotz: [describes XForms submission]
Scott McGlashan: In SCXML we have a set of ECMAScript parameters to submit.

Steven Pemberton: As Charlie said, to move forward we need task forces. It seems like submission is far enough along.
Scott McGlashan: What do you get back?
Steven Pemberton: replace=all gives you a page transition. replace=instance gives you back success or failure events and XML, or text in XForms 1.1.
Leigh Klotz: And in XForms 1.1 we also have full access via the event payload to the response code, response message, content type, and payload.
Scott McGlashan: We have that in CCXML
Rafah Hosn: With JavaScript expr response containing the response.
Scott McGlashan: You want success or failure events for sending.
Leigh Klotz: In XForms 1.0 we found some vendors submitted synchronously and some async so we added a flag in 1.1.
Scott McGlashan: Yes, CCXML and SCXML have that.
Leigh Klotz: Kenneth SKlander of Picoforms and I wrote a document that uses an event loop with xforms-submit-done.
Jack Jansen: You don't get access to the document in xforms-submit-done until it is done.
Steven Pemberton: Mark Birbeck has pointed that out.

Henry Thompson: This is the place to talk about streaming and large XML documents. So you watch the stream go by until the right XPath hits and then you build a fragment and close the connection. Or you write streaming pipelines, but you never have a footprint larger than a couple of hundred K, even though deal with large documents.
Scott McGlashan: We decouple but we don't allow access to the data stream prior to completion.
Henry Thompson: I'd like to do a weekend hack in Firefox.
Dave Raggett: HTTP chunked encoding helps.
Henry Thompson: You can request it but you can't guarantee it.
Scott McGlashan: Are we heading down that path with SIP and packet sizes?
Henry Thompson: I hope not; it may be an incoherent request, but customers bring the own iron to the table.

Charlie Wiecha: So that's a good requirement for submission. Another is HTTPXML. Can someone talk about that?
Dave Raggett: http://www.w3.org/2006/webapi/group/timeline Here is the timeline from Chris; first public draft January next year.
Charlie Wiecha: So we could intercept the V2 one and have alignment.
Henry Thompson: It may turn out that there is interest coming from the AJAX community itself. There is interest in co-routining, lightweight threading in JavaScript, with at least two competing languages that compile down to JavaScript and give co-routining or continuation passing. Brendan Eich has said some kind of threading would be in JavaScript 2.
Leigh Klotz: I find it fascinating that people who are opposed to declarative style and into imperative would then be interested in adopting continuation passing. Is the Y operator next?

Charlie Wiecha: Should we get someone from XHR on this task force?
Steven Pemberton: There is an issue list from Anne von Kesteren.
Charlie Wiecha: On the XForms side, Mark Birbeck is the guru of submission.
Steven Pemberton: And Roland was the previous guru.
Leigh Klotz: I'm happy to be involved as well; I wrote the chapter in 1.0.
Charlie Wiecha: So should we approach Anne and see if he wants to join?
Rafah Hosn: I will join or delegate.
Dave Raggett: And what is in it for Opera?
Charlie Wiecha: They have a scope for V2.
Dave Raggett: And you need to motivate them in the position statement.
Charlie Wiecha: We have an intuition of a need for more events; I hope they are getting at that as well, with a more refined set of events. It may come down to an alignment issue. Essentially the same direction, but spelling; if not we need to regroup.
Rhys Lewis: And the requirements from Rex.
Dave Raggett: If you're committed to HTTP.
Charlie Wiecha: I'd keep it closer to the pragmatic end.
Dave Raggett: Opera has its own events mechanism that doesn't use HTTP.
Rafah Hosn: They're the sole editor.
Dave Raggett: It's whoever signed up to do the work; there's a lot of discussion going on.
Rhys Lewis: They do have 14 specs; that's very ambitious.

Charlie Wiecha: Jack, do you want to sign up for this task force?
Jack Jansen: What XForms has is good enough for me so if I sign up, I'll sign up for something else. I want to import it by reference with two lines of prose.
Charlie Wiecha: That's what this task force is about.
Jack Jansen: If so we'll import the XForms core, with data model, bind, and submit. I'll have to check but maybe some tiny bit from elsewhere. Right now the XForms modularization is just the way we wanted.
Rhys Lewis: It's brilliant; we think XForms is fantastic.

* Lunch

* Data Model Pluggability

Charlie Wiecha: We can combine this with DI/Voice/XForms/SMIL Convergence on Model. So we can report back on XForms modularity around the model, ad that might trigger some thoughts on whether that might be useful. We had thought about a data model module as separate from XForms, with the instance, validation (some combination of Schema and other constraints), submission, actions (e.g. setvalue), and constraints or bind expressions that provide declarative spreadsheet-like computations. Type constraints are a little different from spreadsheet-like calculations.
Rafah Hosn: There's also the lifecycle events that the model fires, recalculate/revalidate/rebuild.
Charlie Wiecha: But not refresh, as that's UI.
Rafah Hosn: There's also the model to the control, but you don't want UI events in SCXML.
Charlie Wiecha: There may be lightweight uses of a data model without control binding. Having these things diced and sliced lets you select a profile that works for you.
Scott McGlashan: Modules that build together; you could get the data model without the constraints.

* Attribue Value Templates

Jack Jansen: I have another one functionality I want, which is attribute value templates, from XSLT. They allow you to, within curly braces, refer to values in your model and have them be interpolated.
Steven Pemberton: A great use is <img src="..." ... > just as an example. I've always been a bit frightened of adding this because it requires a committment almost from all of W3C.
Jack Jansen: You invalidate existing URLs, or maybe no you don't.
Steven Pemberton: It's in the UI binding.
Jack Jansen: It's not in the model; it's a piece of technology I'd like to be able to import easily.
Charlie Wiecha: We have that on the list already as model/view binding AVT. We don't want to say to model users that they must have a view.
Jack Jansen: We're not thinking of doing that.
Charlie Wiecha: You want AVTs but no event-model binding?
Jack Jansen: Right.
Rhys Lewis: We have AVTs but we don't need it in the model because you've already got computation.
Rafah Hosn: What do you put in the curly brackets?
Steven Pemberton: An XPath expression.
Scott McGlashan: When does it get evaluated?
Rhys Lewis: Whenever the processor says it does.
Steven Pemberton: So XForms would do it when the value changed.
Rhys Lewis: It's another way of doing calculations.

* Pluggable expression languages

Rafah Hosn: If another way to do it was not with bind but with pluggable events, wouldn't that solve the problem in another way? If I wanted to do a computation on the data model without bind, but with executable content?
Charlie Wiecha: Why not use bind xpath and have it be called by the processsor?
Rafah Hosn: I might not have xpath.
Rhys Lewis: We have pluggable expressions. The only implementation today is XSLT xpath in DISelect.
Jack Jansen: In voice we have expr with ECMAScript.
Charlie Wiecha: Are you looking for a script-oriented calculate in the model?
Rafah Hosn: Yes, we'll get pushback and want to use JSF-like constraints and actions on the data model, which aren't calculate and relevant. If we say that, semantically, it causes the model to recalculate, and revalidate, you get the semantical behavior but don't impose a particular way of doing the calculation.
Charlie Wiecha: You still have to say f(a,b)=>c so the dependency graph can work.
Rafah Hosn: But a and b can be ECMAScript.
Charlie Wiecha: So some notion of the function signature for computing the dependency graph, without having to parse ECMAScript.
Scott McGlashan: We talked about something on the root node for the expression language.
Charlie Wiecha: This isn't about the language; it's about c=a+b; internally the XForms processor builds a dependency graph. It can do that transparently becuase it's consistent to parse the XPath expression.
Rhys Lewis: That ruins your day; because in DISelect we use the delivery context.
Steven Pemberton: Can't we model the delivery context as a readonly model.
Rafah Hosn: It is modified by the device, or the user.
Steven Pemberton: So don't make it readonly.
Jack Jansen: That was our discussion, it's mutable but readonly. Yours is readonly but mutable.
Rhys Lewis: Actually, no. In general, the model for adaptation is fully distributed. Potentially, at any point in the chain someone could modify it. In practice we have no idea of how to model the negotiation in a multi-stage process. We cannot modify it today but it is coming.
Steven Pemberton: But it still doesn't...the details are discussable. Can't you just make it a model?
Rhys Lewis: We need some explicit mechanism flagging what has changed.
Leigh Klotz: You get DOM mutation events.
Charlie Wiecha: ...
Steven Pemberton: ...
Jack Jansen: You need a namespace.
Rhys Lewis: So it looks like a model, but not the model.
Dave Raggett: Multiple data models...
Jack Jansen: If there are multiple models in the document, which model do you insert the SMIL state?
Charlie Wiecha: You would cook up an instance.
Jack Jansen: If there is only one model, it's clear.
Charlie Wiecha: There's one model tag but multiple instance; one for DI, one for scratch.
Jack Jansen: You can have multiple models as well.
Steven Pemberton: Yes.
Jack Jansen: If I have one SMIM document with one model it's clear, but with two models, where do I insert my SMIL state?
Leigh Klotz: Can't it be in both?
Rhys Lewis: If one represents application context and one delivery state it doesn't make sense. Charlie:...
Rhys Lewis: There are 350-400 of them but I don't expect to give them except through xpath expressions.
Rafah Hosn: DCI gives your path-based access...
Charlie Wiecha: If you want to use the XForms recalc process you can surface them in a model, and use the XForms expressions with the XPath functions, you can.
Rhys Lewis: I don't have to make them explicit.
Jack Jansen: We could to that as well, just a facade of XPath functions on top of it. You can't change them anyway. You would just have all the expressive power be dependent on custom tests.
Rhys Lewis: But you don't have to have an explicit representation. They you can facade with different functions, for example ECMAScript. There's no path-based delivery access. We don't think there is a single common view. The functions are straightforward; how many pixels across my device, etc. DCI is not required.
Charlie Wiecha: Those are more suitable for use in binding expressions. Just a function doesn't give you the ability to recalculate.
Rhys Lewis: Knowing when to recalculate is the problem?
Charlie Wiecha: So you have to tie it to an element.
Leigh Klotz: So you use a DOM facade and just issue mutation events on the areas that change, and that can drive the changes through the dependency graph and get the only the expressions that need to be recalculated done.
Charlie Wiecha: So we're deep-ending on this.
Rafah Hosn: I think author-controlled validation is a good thing. I think calling the validation when a chunk has happened is a good thing. I want to require or discuss not having the processor revalidate after every change.
Charlie Wiecha: It's a batching argument. You make changes and then are done, and don't care about intermediate states.
Rhys Lewis: That could be an extension; the default as in XForms could be to validate.
Charlie Wiecha: Rafah is looking at times, not code blocks.
Rafah Hosn: It's interspersed, not lexical.
Rhys Lewis: I don't disagree at all; I want that.
Charlie Wiecha: We dealt with that in XForms with deferred updates; we might be able to re-use that.
Rafah Hosn: ...
Charlie Wiecha: Not roll back.
Scott McGlashan: I don't want to be doing it in my client.
Rafah Hosn: Just don't specify a schema on the model.
Leigh Klotz: And don't use bind type if you don't want type validation either.

* setvalue and assign

Charlie Wiecha: So SCXML assign has the same semantics as setvalue?
Rafah Hosn: You can assign a value to an xpath expression. We haven't yet properly defined it but you can assign a nodeset to a location in the data model. < assign location="/foo/rafah" expr="/rafah/classes"/> We have a bug in the defiinition today and don't say how it is done.
Rhys Lewis: You have variables?
Rafah Hosn: We have scratch space vars.
Scott McGlashan: We removed them; everything is in the data model.
Jack Jansen: Why do you have them in DISelect?
Rhys Lewis: Because you can use it without Dial, potentially in XHTML1.
Jack Jansen: The variables in DISelect appear to save keystrokes.
Rhys Lewis: Or recalculations.
Jack Jansen: That put us on your model but it took a long time before I noticed your variables are scratch; we need a data model.
Rhys Lewis: We've got a data model; we have XForms. If you have comments for last call, that's fine, we'll take them.
Rafah Hosn: We have all our variables inside the data model.
Rhys Lewis: We can do that in Dial but not in DISelect.
Charlie Wiecha: You could support the XForms setvalue as well as your assign?
Rafah Hosn: Yes, we could extend...
Scott McGlashan: Pluggability of assignment levels?
Charlie Wiecha: Let's get to that; let's see if we can nail down the XML/XPath one.
Scott McGlashan: Other actions?
Jack Jansen: An event that is raised when a value in the model has changed. YOu have it in XForms
Charlie Wiecha: xforms-value-changed
Jack Jansen: Yes, that's only in views. I want to repeat until your quiz score is over 50%.
Charlie Wiecha: You have a bit of a view.
Steven Pemberton: Have you got a binding of the value? It doesn't have to look, just be bound to it.
Leigh Klotz: Can you say repeat while x <= 50?
Jack Jansen: I don't want the calculations there.
Leigh Klotz: You can specify relevance and bind your UI for that quiz to that node.
Charlie Wiecha: And listen for the relevance node, with a trigger.
Rhys Lewis: But he doesn't have XForms UI.
Leigh Klotz: It's not a trigger, it's a group, because it is a UI section that listens for relevance.
Charlie Wiecha: Rafah doesn't need any UI but you would be surprised when a view is needed.
Rafah Hosn: Is there any value in asking the model to fire once rather than having to import the XForms data module and the UI module just for the group.
Charlie Wiecha: Do you want events but not controls?

* binding for events

Jack Jansen: For me it would be nice that in the model I could say whenever that thing changes, raise event.
Charlie Wiecha: You have to say where that event goes.
Rafah Hosn: Where that goes.
Steven Pemberton: Can trig have a ref?
Rafah Hosn: He has to have a ref on it. But at that point he's pulled in the whole module.
Leigh Klotz: He wants the attribute, not the elements.
Jack Jansen: So the authors have to put this thing in their document?
Steven Pemberton: You have to have something somewhere that says to listen.
Jack Jansen: Keypresses happens; they don't happen to an element.
Charlie Wiecha: This is why I said that model-view binding is separable from the controls. He wants single or multiple-node binding without importing the widgets. There's a general binding and I want the behavior, but want to separate the binding aspects from the particular widgets.
Rhys Lewis: Is that the only additional thing you wanted
Jack Jansen: I'll come up with more. I can do everything I want to do but what would make my life easier?
Rafah Hosn: It's not optimal.
Charlie Wiecha: It could be sliced a little finer.

* variables and scope

Charlie Wiecha: How do you know the scope?
Scott McGlashan: You do explicit assignment, multiple x's with application, session, etc. session is readonly and immutable.
Charlie Wiecha: Does the application carry over into V3?
Scott McGlashan: It allows data persistence through page changes and is popular. The leaf pages are URI accessible and refer to the root page by URI which contains a data model and event handlers. Some people have asked for cascaded root pages as well.
Charlie Wiecha: You could have a model in the application level document and then you need a way to resolve references across documents because they point to IDs that aren't local.
Rafah Hosn: Do you ever want to copy data from one scope to another?
Charlie Wiecha: A live bind would cause you a little trouble.
Scott McGlashan: There's no liveness in assignment.
Charlie Wiecha: In XForms we don't allow bind expressions to go across physically different models.
Scott McGlashan: I'd see this as the same model, but different partitions.
Charlie Wiecha: Spread across different documents.
Scott McGlashan: Anonymous scope becomes this page's scope. The model would remain constant. Instead of having a data model glued into the document, I'd prefer to have one outside the scope of the document.
Rafah Hosn: Portions are visible.
Scott McGlashan: One floating data model, but not locked and tied into them.
Rafah Hosn: Has XForms ever discussed scoping in the data model?
Scott McGlashan: Keeping data across page transitions is well used. You can shadow variables and there are visibility rules.
Leigh Klotz: You could use XForms, with a model in the host document and then combine switch/case or group with relevance and use xi:include with an activation model cut down on the page markup from being loaded. That doesn't give you the cascading being considered for VoiceXML 3 though.
Rhys Lewis: You can use an external instance?
Leigh Klotz: You can load it and modify it and put it back, but there is no synchronization.
Charlie Wiecha: You can build the application scope and flush back when the page loads.
Scott McGlashan: That's more complex than attaching to a model outside the document; you don't copy, just change pointers.
Charlie Wiecha: Some kind of soft link. That's an interesting requirements.
Scott McGlashan: Yes, especially if you plug in ECMA flavor or XML/XPath flavor. We need a good story there.
Charlie Wiecha: But not in SCXML.
Scott McGlashan: In CCXML. But in SCXML we'd like it.
Rafah Hosn: We'd like to keep the page transition data.
Leigh Klotz: I noted that Web Forms 2.0 has client-side persistence, big cookies basically. It remains to be seen what acceptance that will have with end users.
Scott McGlashan: Some of the browsers suppor this already.
Leigh Klotz: Yes, Firefox has the temporary area.

* Pluggability

Charlie Wiecha: So what about pluggability?
Scott McGlashan: I'd like to have either XML/XPath or JSON/ECMAScript. The event payloads would be treated as XML documents, if we have both.
Rafah Hosn: I like Leigh's idea of an attribute on the XML root and I'll bring that to the group.
Charlie Wiecha: In SCXML v3 you want either an XML model or a JSON/ECMAScript model. But that's a separate questions from what an XML model looks like.
Rhys Lewis: ...
Charlie Wiecha: Isn't that orthogonal? Validation, etc. are properties of the XML model, not a property of the ECMAScript model.
Rhys Lewis: I could use ECMAScript and CSS path selectors.
Charlie Wiecha: So you want an XML model but path expressions in ECMAScript?
Rhys Lewis: Surely it's only a function of the interface.
Rafah Hosn: It doesn't matter how you implement it.
Rhys Lewis: I can fake it up and let people access it.
Charlie Wiecha: I think that's leaky.
Rhys Lewis: In DISelect, we use ECMAScript facades. Whoever access the model uses the function.
Charlie Wiecha: That's a function of your implementation, not a model issue.
Rhys Lewis: Exactly, I keep the XML model.
Rafah Hosn: In SCXML, the model is XML but we present it in ECMAScript.
Rhys Lewis: And that's our problem, not yours. Similarly with events.
Rafah Hosn: In our Apache implementation, we have can have no data model.
Charlie Wiecha: That's session scope; we're talking about XPath expressions pointing to the application model. And I heard a requirement to access those through ECMAScript.
Rafah Hosn: Yes, ECMAScript, XPath, EL.
Charlie Wiecha: So it's an XML model but you want to treat it as XPath or ECMAScript on the transitions.
Rafah Hosn: I need it for evaluating for the exprs; I can use EL or JEXL.
Charlie Wiecha: The model wasn't the application; it was the server expression scope, so it made sense for the Apache implementation.
Scott McGlashan: But you're getting the values from events so what you're plugging in is event data..
Charlie Wiecha: Delivered as JSON objects?
Scott McGlashan: I think they're opaque objects. We could say XML.
Leigh Klotz: In XForms we've proposed an event context function with well-known name arguments so you can get access to live data nodes from the instance if necessary, for example in an insert event. The rest of the values can easily be an XML response.

* Break

* accesskey

Steven Pemberton: What would you like to know.
Jack Jansen: Preferably I would like to be told what to do. accesskey is old. access and role could be made to fit the SMIL model but we get the impression that we need something better. We want to be good W3C citizens and interoperate.
Rhys Lewis: What makes you think that role is not the right thing?
Jack Jansen: We got that impression from Al Gilman.
Rhys Lewis: He asked me to include it in sources and actions.
Jack Jansen: The predefined list of roles in XHTML 1, was 7?
Rhys Lewis: 10?
Charlie Wiecha: There are people doing ontologies.
Rhys Lewis: It's in working draft?
Jack Jansen: This is what I've been using: http://www.w3.org/TR/2005/WD-xhtml2-20050527/mod-role.html
Rhys Lewis: That's not it. http://www.w3.org/TR/aria-role/
Steven Pemberton: I don't think we have anything better.
Jack Jansen: We have accesskey event so we need an accessrole event parameterized by role name, and then we have the functionality we have now but with role titles for other UIs to find it.
Steven Pemberton: I think the idea solution for accesskey is to split it into two things: intent based, and a mapping from keyboards.
Rhys Lewis: We took that in UWA.
Jack Jansen: We looked at the XHTML 2 version and this extends the XHTML2 set?
Rhys Lewis: These are namespaced. It's in the accessibility namespace.
Jack Jansen: If someone wants to use this, they can use it. We need to see if anything is obviously missing. The set of roles in XHTML is static.It's not enough. Potentially this could be a more complete set although it is fairly long now.
Rhys Lewis: You might suggest additional roles.
Jack Jansen: For example, from daisy books, you want next chapter, previous chapter, next figure, those types of roles. But that is only from a daisy perspective; from a television perspective you want a different set.
Rhys Lewis: ...
Jack Jansen: The Aria document is a WD. So it would be a non-normative reference to XHTML2, then to this, and then provide input to WAI or ...
Rhys Lewis: And to us as well.
Steven Pemberton: You pointed to modrole but there's a separate role spec. This is internal but will be published (in the queue): http://www.w3.org/MarkUp/Group/2006/WD-xhtml-role-20061108/ It's already implemented in Firefox.
Jack Jansen: What is the relationship between this an Aria?
Steven Pemberton: The Aria stuff is values for the attribute.
Leigh Klotz: This is part of RDFA?
Steven Pemberton: It's related. Aria roles are just values for the role attribute.
Leigh Klotz: What does it mean to be implemented in Firefox? I see no processing.
Steven Pemberton: Almost certainly through the accessibility hooks. http://firefox.cita.uiuc.edu/document/style/roles.php
Rhys Lewis: http://developer.mozilla.org/en/docs/Accessible_DHTML#Supported_roles_and_properties
Jack Jansen: So Aria is too high level and role is too low.

Jack Jansen: Does slidey use role? I would like a role for next-slide and previous-slide. It's temporal navigation.
Dave Raggett: There's general navigation stuff, but there's always going to be a small set of common actions.
Jack Jansen: Next is so common in multimedia documents.
Rhys Lewis: When you create those new roles, we would like to know. There's more than one kind of next.
Jack Jansen: Small next, bigger next, etc. The Daisy people have been thinking about this for a long time.

Rhys Lewis: Any more on accesskey?
Steven Pemberton: Task force so we can agree on the binding mechanism.
Rhys Lewis: We have that action for UWA, to produce and edit that results of that task force. Assuming you encourage your AC reps to vote for the UWA charter.

* Summary

Task forces (with proposed champions, some not yet confirmed):

Dave Raggett: Do we want to write a paragraph summary?
Steven Pemberton: For HCG?
Dave Raggett: I'm happy to delegate this task to the chairs.
Steven Pemberton: The chairs accept.

* Next Steps

Jack Jansen: When is the next step?
Steven Pemberton: The next step is to take it back to the HCG chairs. There were a number of people in HCG who didn't want a member-only meeting; they wanted a public meeting. So do we now do a public one? I'm not particularly keen on repeating this but wouldn't mind doing something different that is public.
Rafah Hosn: We have the task forces.
Charlie Wiecha: I'm unclear on which are formal and which are email collaboration. The big buckets were submission and model.
Rafah Hosn: events
Steven Pemberton: Access
Rafah Hosn: No navigation; that goes back to CDF