Erik Bruchez, Orbeon
Leigh Klotz, Xerox (minutes)
Mark Birbeck, x-port.net
Nick van den Bleeken, Inventive Designers (chair)
Paul Butcher, x-port.net
Roger Pérez, SATEC
Doug Scheppers, W3C
Uli Lissé, Dreamlabs
Keith Wells, IBM
Keith Wells: I am still working on the Mozilla report.
Nick van den Bleeken: Please send me mail about your completed items.
Nick van den Bleeken: Personally I don't
understand why when you switch back when you submit it the default
namespace is xhtml.
Paul Butcher: This looks like a
Mozilla implementation bug to me. Formsplayer doesn't do
this.
Nick van den Bleeken: Erik commented that we need
something to omit namespaces.
Paul Butcher: That's a slightly
different thing, for non-conflicting namespaces. If someone had
xmlns:x and xmlns:y in the namespace, something to omit them.
Nick van den Bleeken: I don't think that's
Mozilla's problem.
Erik Bruchez: I thought I understood
the problem. The spec doesn't say much about the spec and inline
instances.
Mark Birbeck: I didn't understand your
followup comment. You said XProc has the facility to exclude
namespaces and we have essentially the same thing, with
includenamespaceprefixes.
Erik Bruchez: Here we aren't talking
about submission.
Mark Birbeck: Then I don't understand
the point.
Erik Bruchez: It's an inline instance
and let's assume you have xf:instance and the root child element
for the new DOM. Syntactically, when you put that there, it's not a
new DOM, so you need some logic that determines what happens to
namespaces. That element will have in-scope the xforms prefix
mapped to the XForms namespace.
Mark Birbeck: But nothing happens to
that DOM until you do a submission. It has no impact on the outside
world until it comes out. If you use an XPath expression it's still
got to work.
Erik Bruchez: I see what you mean
regarding the submission and I didn't understand that's what you're
talking about. However, I'm not sure it's strictly true.
Technically you have functions in XPath to access namespace nodes.
The namespaces that are in scope do matter. Let's assume you do an
insert of a subtree of that instance into another instance. The
infoset properties with namespaces in scope will be copied over to
the other instance so it does have an impact on the infoset. Let's
assume you have a document containing attributes with QNames.
Mark Birbeck: Sorry to interrupt, but
we're not disagreeing. I think they should be preserved.
Erik Bruchez: That's the problem I'm
trying to solve. Sometimes users want to put instances inline. I
can see some enhancements.
Nick van den Bleeken: What problem does this
solve?
Erik Bruchez: The namespaces in scope
are an important part of the infoset. The QName in attribute is an
example. If you have qname="foo:bar" the XML parser has no way to
know. It also impacts serialization when you do submission.
Nick van den Bleeken: We have the same in XForms,
which we they have in XSLT, to say which to include.
Erik Bruchez: The attribute in XProc
which I like very much lets you put the XML document inline and
lets you include namespaces in scope with a clean document. It can
impact processing further down the line. Also the default namespace
catches people all the time.
Nick van den Bleeken: We can add this as an issue
and we need to reply saying it's a Mozilla bug. Erik, do you
want
Action 2008-07-16.1: Nick van den Bleeken to reply that it's a Mozilla bug. http://lists.w3.org/Archives/Public/www-forms/2008Jul/0001.html
Erik Bruchez: I don't think it's an urgent issue to add the feature. We don't have it.
Nick van den Bleeken: Now that Mark is here we
can discuss this further.
Mark Birbeck: I was a bit
disappointed; it seems like we come around to this every few
months.
Nick van den Bleeken: We've already got four; John
and Steven were afraid it would be too many specs for the
track.
Mark Birbeck: I don't know; I don't
know what I'm being asked. If it's too many specs we should bundle
them up. If it's up for discussion, let's try to get a couple of
low-level specs out. It's for adoption. We agree, then a month goes
by, and we forget.
Nick van den Bleeken: We discussed small modules
in one bigger document.
Mark Birbeck: The one bigger document
could be guidance on how to use features together. The smaller
documents can help provide smaller features that people can adopt.
You get early implementations, and you can get discussion of
smaller specs on mailing lists. The discussion is about features
rather than big issues.
Nick van den Bleeken: When Steven and John are
back we can discuss this more. One issue might be last call
comments, and more resources. Or do you think it will be
equal?
Mark Birbeck: One last call comment on
any one module will hold up the entire document, whereas if you
break it down, it can carry on through. I see it as Agile: release
early, release often.
Nick van den Bleeken: AC Reps need to vote for all
of them.
Mark Birbeck: I'm not sure what to
say; we've been discussing this for three years.
Isn't it about time we add an xforms-control-initialize event?
Nick van den Bleeken: What about adding this to
XForms 1.2?
Mark Birbeck: Is it cancelable? Is
there additional context information being presented here?
Nick van den Bleeken: The valid, invalid, etc. are
not sent on initialization.
Mark Birbeck: We can just send them on
initialization.
Leigh Klotz: How about just event
context the on existing event (xforms-valid etc.) that says whether
it's at init time or not? Now we have @if and can use that.
Mark Birbeck: Or we could have one
event that has the current state of the control. That would reduce
the number of events.
Nick van den Bleeken:
Leigh Klotz: Chiba has
chiba-state-changed that is sent when the state changes but the Rec
doesn't say to send an event; perhaps we can ask Uli.
Uli Lissé: I tried to explain
the differences, but I don't think that Notification events as they
are today are suited to communicate every change to a control.
There are certain aspects not covered by the XForms events; for
example, an input control could change its bound datatype and you
have to switch its representation. Rebuild, for example. This isn't
covered by the standard XForms events.
Leigh Klotz: There are Events for
model-control communications and some for form authors. It's not
clear which this is for.
Uli Lissé: It would be best to
have both.
Leigh Klotz: Then we need two lists
and we need to put the events in the appropriate list and we need
to see which lists need what new events.
Nick van den Bleeken: Don't you have an action
item to do something like that Uli?
Uli Lissé: No, not on this
list. There are other issues, such as xforms-value-changed which
doesn't have the value. We have a separate event in Chiba.
Nick van den Bleeken: We should discuss this when
John gets back. And the init context info on the existing MIP
events sounds good.
Uli Lissé: Yes.
Erik Bruchez: Also on controls
newly-bound to nodes, or instance replacement. Or when the binding
changes
Uli Lissé: This reminds me of
another issue you brought up Erik, with instance replacement. Then
you lose information because the controls don't keep their state;
the state is kept at the model level.
Erik Bruchez: To me those events are
utterly broken. The only way I see this working is having the
controls keep their state, including previous value and previous
MIP, and on refresh they ... It's not a matter of adding context
and information; we have to make them function as form authors
expect. I believe it was decided that someone would make a
proposal; I was supposed to work on it unofficially. Nobody has yet
a complete proposal for new and modified events.
Uli Lissé: I would like to dig
into that but I'm moving to a new apartment for the next two or
three weeks.
Erik Bruchez: I wish I could work on
it too.
Nick van den Bleeken: I will leave the item on the
agenda and we will discuss it when John is back.
Nick van den Bleeken: I will do a quick
overview and talk about some remarks Mark made. For dispatch, if,
and while, I found these straightforward; however, there was
something tricky on dispatch that I haven't done: it does different
things with xforms events and non-xforms events; you can't override
bubbles and cancelable. If we want to make this not depend on
XForms we have to be able to classify these events based on some
other property. Also Mark said XForms 1.1 still uses XML Events 1,
and there is now XML Events 2, which contains the dispatch element
and event function. What about XML Events 2?
Uli Lissé: Is it a Rec yet? And
in refactoring should we refactor first then add features?
Leigh Klotz: There are forward
reference rules and when we're in WD it's ok for us to refer to it
from our WD.
Mark Birbeck: XML Events 2 is further
along so I don't think it's a problem. I also think we'll save work
moving to it.
Uli Lissé: But what if we do it
in every module?
Mark Birbeck: This spec already does
what we need, and I helped put it in.
Uli Lissé: But your message
spec also has something new.
Mark Birbeck: I see. But this spec is
already reviewed.
Uli Lissé: I see your point but
I'd like to make one step after another.
Nick van den Bleeken: Did you see my reply, Mark?
I don't see any functional problems from 1.0 to 2.0. The only thing
is the dispatch action which allows you to specify the cancelable
and bubbles on all events. Are there any other things that are
different from XForms+XML Events 1. if and while aren't a problem
because you can define the context, and the others aren't a
problem. ... convenience attributes ... script is new, I
think.
Mark Birbeck: I don't think there is
anything else.
Nick van den Bleeken: So we automatically get the
script action. Some might not like that.
Leigh Klotz: If we describe XForms 1.2
like this and you implement it and don't implement script, then
you're not implementing XML Events 2, not not implementing XForms
1.2.
Nick van den Bleeken: But we would refer to it
normally.
Mark Birbeck: Send it as a comment to
the XML Events 2 list. Also, using XML Events 2 is useful because
it will be used in other places, such as SVG.
Nick van den Bleeken: We have events that can be
changed (bubble, cancel) and those that cannot. If we go to XML
Events 2, then we can't do that. I'm not sure you can do it in
XHTML modularization.
Leigh Klotz: You can do it with RNG
modularization. Just make two enumerations of events that can't be
cancelled and events that can't bubble and introduce that
constraint into the schema, and modules can add to the lists. I
think this would be a good comment for the XML Events 2 WD.
Nick van den Bleeken: What is the reason for this
restriction?
Mark Birbeck: I don't know why; I
never understood the issues. Perhaps we should revisit it.
Nick van den Bleeken: We need to describe the use
case; can anybody describe it?
Nick van den Bleeken: OK, any other comments on
the action model?
Nick van den Bleeken: So do we want to go to
XML Events 2 or do we stay with XML Events 1? I am in favor of
going to XML Events 2 because of the reasons Mark said. I know Uli
wants to stay with XML Events 1.
Uli Lissé: [irc] no!
Mark Birbeck: If we want to stay with
XML Events 1 and do factoring in stages, we should drop @if and
@while.
Nick van den Bleeken: But we need @if and @while
in our actions module.
Mark Birbeck: You could do it in two
stages; create a module which contains the pre if and while and
then add XML Events 2.
Nick van den Bleeken: That sounds like even more
work. Uli?
Uli Lissé: I am in favor of XML
Events 2 and then do the modules first and then add new features. I
see the value of XML Events 2 and I don't think it's too much work
to split and then add modules.
Leigh Klotz: Take this actions
document through the W3C Rec process?
Uli Lissé: No, just produce the
spec-ready text and see what we have. Maybe I'm not concerned if
you add XML Events 2 right now, because it's not complicated like
binding expressions which might have side effects. Just go ahead.
I'm not concerned with XML Events 2 right now. I just want to say
that it would be a better procedure to have spec-ready text for the
modules first.
Nick van den Bleeken: I would prefer that also but
in this case it's because the XML Events 2 spec is based on XML
Events 1 feedback.
Leigh Klotz: So are we going to send
feedback about script?
Nick van den Bleeken: I don't have any problem
with it but others might.
Mark Birbeck: I do have some feedback
but it's separate from this discussion. In current browsers there's
not any way from stopping the script from executing and we need to
have it execute in actions. I'll have to check on user agents that
don't support script.
Nick van den Bleeken: It does say the languages
that are supported depends on the ones embedded.
Nick van den Bleeken: So if nobody has any objections I'll do it.
Resolution 2008-07-16.1: We move to XML Events 2 for XForms 1.2
Action 2008-07-16.2: Nick van den Bleeken to move Actions module for XForms 1.2 to XML Events 2.
Nick van den Bleeken: We should hold off on the instance and binding modules until Charlie and John are back. Should we end early and discuss the instance data module next week. Please read he spec-ready text for next week: