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