W3C Forms teleconference July 16, 2008

* Present

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

* Agenda

* Previous minutes

* Implementation report progress

Keith Wells: I am still working on the Mozilla report.

* Action Item List


Nick van den Bleeken: Please send me mail about your completed items.

* Default namespace when submitting data question

http://lists.w3.org/Archives/Public/www-forms/2008Jul/0001.html http://lists.w3.org/Archives/Public/public-forms/2008Jul/0024.html

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.

* Module bundling into fewer specs

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.

* Validity notification on initial or hidden data


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.

* The Actions Module

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.

* Administration

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:

* IRC Log

* Meeting Ends