W3C Forms teleconference February 8, 2012

* Present

Alain Couthures, AgenceXML
Leigh Klotz, Xerox
Nick van den Bleeken, Inventive Designers [IRC]
Philip Fennell, MarkLogic
Steven Pemberton, CWI
Kurt Cagle, XMLToday
Uli Lissé, DreamLabs [joined late]
Erik Bruchez, Inventive Designers/Orbeon [joined late]

* Agenda


* XML Prague

Steven Pemberton: Alain, Nick, and I will be in Prague, and possibly Uli.
Leigh Klotz: betterForm said they will announce a release at XML Prague.
Steven Pemberton: Yes, 4.0. They'll be there?
Alain Couthures: I will be presenting about eXistDB.

ACTION-1864 Steven Pemberton to announce BetterForm 4.0 on home page.

* Why is https: optional?


Leigh Klotz: Needs action item to implement resolution

ACTION-1865 Steven Pemberton to make https not optional in XForms 2.0.

* AVT in XForms (Review Spec / Schema)

http://lists.w3.org/Archives/Public/public-forms/2012Jan/0020.html http://lists.w3.org/Archives/Public/public-forms/2012Feb/0013.html

Leigh Klotz: I wonder if we need to backfit this

    <header><name>foo</name><value value="abc+3" /></header>

    <header name="foo" value="{abc+3}" />

Steven Pemberton: It's a transition period.
Leigh Klotz: I think we deprecated all the child value elements already.
Leigh Klotz: Currently we have header/name with multiple value siblings. Also if we want to do one header with multiple values, we can repeat the whole header element.
Steven Pemberton: That's a good point. Should we resolve?
Leigh Klotz: I'd like to wait for Nick's response but I think we should.
Steven Pemberton: Would @name be an AVT as well?
Leigh Klotz: Yes.

Kurt Cagle: There are no examples of AVT usage in the host language yet.
Leigh Klotz: Yes, wherever we say that we should support AVT in the host language we should say that.
Kurt Cagle: Also, in those contexts, we should specify that changes to the attribute values don't propagate back to the model.
Leigh Klotz: They are like @value, not @ref.
Steven Pemberton: Could you send a note about that to the list?
Kurt Cagle: Sure.
Steven Pemberton: Also we need examples.

* Use of xslt:output attributes in submission


Steven Pemberton: We designed the submission element on top of xsl:output and took attributes from there and added them to submission. XSLT2 added extra attributes and we should decide if we want to include them or not. I don't propose to add them, but we should examine them.
Leigh Klotz: @method is a challenge.
Steven Pemberton: We didn't have it the first time.
Leigh Klotz: @method=xhtml does something different from xml but it may be less important as time goes on.
Steven Pemberton: Right. Implementors should let us know if we need them.
Leigh Klotz: We should point out ones that are a problem, like method.
Steven Pemberton: What is undeclare-prefixes? Is it like our includenamespaceprefixes?
Leigh Klotz: And name?
Philip Fennell: name lets you define different outputs and use them from the main part of the transform.
Steven Pemberton: Let's close this and see if anyone wants to argue for adding any of these attributes.

* Made basic event properties available for the event() function


Steven Pemberton: This is a heads-up from Nick. I can't imagine it's a problem for anybody.

* JSON/mediatypes/src/replace


Steven Pemberton: We already decided not to do this.

* Expand data model of ref to an arbitrary sequence


Steven Pemberton: Can we do this without Nick?
Leigh Klotz: I can see John wanting to discuss this as well.

* Added optional id parameter to the context function


Steven Pemberton: This is a heads-up from Nick. It would be good to have an example.
Leigh Klotz: What about using with an id that is inside a repeat?
Uli Lissé: [joins]
Steven Pemberton: There has to be an ancestor.
Leigh Klotz: Does binding elements mean bind or xf:*/@ref elements?
Steven Pemberton: Right. I don't know.
Leigh Klotz: setvalue out repeat referring to one inside.
Steven Pemberton: No that's not allowed because it's not an ancestor.
Leigh Klotz: Then in that case he must xf:*/@ref because bind cannot be the ancestor of anything in the UI.
Steven Pemberton: Right.
Steven Pemberton: It should be answered by implementors. But he seems to think it's ok.
Leigh Klotz: The note looks OK to me.
Steven Pemberton: Then we should answer that we shouldn't limit it.

* Added iterate attribute section to the XForms 2.0 spec

http://lists.w3.org/Archives/Public/public-forms/2011Dec/0002.html http://www.w3.org/MarkUp/Forms/wiki/XForms_2.0#The_iterate_attribute

Steven Pemberton: Fixed a spelling error in the id anchor.

Leigh Klotz: I believe we came to a consensus and John was happy that he could test to see if a node had a parent, and if it didn't have a parent it was deleted.
Steven Pemberton: Yes, let's note that and wait for Nick and John.

* 7.9.5 Serialization as application/xml


Steven Pemberton: Do we update this from XSLT 1.0 to XSLT 2.0?
Leigh Klotz: If we're not going to add any of hte XSLT 2.0 output attributes...
Steven Pemberton: I don't know enough about the serialization used in 2.0 to say whether they've changed anything other than responding to the new attributes.
Leigh Klotz: There's a whole spec on XSLT serialization, second edition December 2010: http://www.w3.org/TR/xslt-xquery-serialization/
Steven Pemberton: And XQuery 1.0. That looks like a good thing to read. It answers some of my questions. I feel very inclined to reference this document.
Leigh Klotz: I think if do we should add the attributes, since this document defines them.
Steven Pemberton: How do you serialize, Alain? And Nick?
Alain Couthures: I use XSLT 1.0.
Steven Pemberton: Do you think we should refer to XSLT 2.0?
Alain Couthures: I don't know yet.
Steven Pemberton: Should we leave it as an issue in the spec?
Leigh Klotz: If you implement only XPath 1.0 then you're unlikely to implement XSLT 2.0 serialization.
Steven Pemberton: Quite. But it doesn't sound like anybody has strong opinions so I'd call it out in the spec, as an editorial point.
Leigh Klotz: That sounds great.

ACTION-1866 Steven Pemberton to Add XForms 2.0 editorial note, asking whether to use XSLT 2.0 serialization for submission http://lists.w3.org/Archives/Public/public-forms/2011Dec/0019.html

* Error Handling

http://lists.w3.org/Archives/Public/public-forms/2011Nov/0027.html http://blog.orbeon.com/2011/11/more-resilient-error-handling-in-xforms.html http://wiki.orbeon.com/forms/welcome/xforms-error-handling

Erik Bruchez: We think the XForms spec has too many requirements that terminate the XForms Processor, in particular xforms-binding-exception and xforms-compute-exception. We implemented something a little bit different from what's in the spec. Consider a form that is first shown to the user and will have interaction with the user; it's a problematic behavior if the user performs an action that causes the processor to stop working. There doesn't seem to be any provision for recovering from that kind of error. Let's say you have an XPath expression which either never ran, or an OK and at some point causes a dynamic error. For example, in XPath 2, casting a value to a type. A cast failure would cause a dynamic exception. It seems this would fall into a compute exception. We don't have xforms-compute-error or xforms-binding-error which are not fatal. I think there should be an option for authors to recover. We implemented a set of rules to follow when something goes wrong, instead of stopping the engine. We don't do this when the form is initially shown, since that's something we show the developer. But later after user interaction, we try to recover. We dispatch events and you could stop processing, but not necessarily. Let's say an XPath expression fails at runtime. You take a default value for that expression and instead bind that control to nothing and it becomes non-relevant, then we dispatch an event to the application. So if you have a bug and something bad happens, then the user could possibly recover by saving data.
Erik Bruchez: At the very least, we should give form authors the option to continue when something happens, typically with XPath expressions and dynamic errors. We implemented that and dispatch different events.
Leigh Klotz: If the exceptions aren't caught does that turn into the spec error?
Erik Bruchez: No. We let you try to continue after informing the user.
Steven Pemberton: These are the result of an event, right? We submit an event whose default action is to terminate? Couldn't you catch them?
Erik Bruchez: You cannot cancel this event.
Steven Pemberton: Is that the essential problem? Wouldn't that make it easier?
Erik Bruchez: It could be done; you also have to say what happens. For example, < input ref="..." and there is an error, you have to specify what happens to that binding. And for output, itemset, etc. We said they resolve to an empty nodeset or empty value.
Steven Pemberton: I think this is good. I think it's an essential part of any mature application system, that you can trap and try to recover from errors.
Leigh Klotz: I think we should discuss it more. There's also saxon:try and xslt:try, in addition to the compute exception.
Steven Pemberton: Yes, maybe a F2F issue.

* IRC Minutes


* Meeting Ends