W3C Forms teleconference March 21, 2012

* Present

Nick van den Bleeken, Inventive Designers
Philip Fennell, MarkLogic
Steven Pemberton, CWI (chair)
Leigh Klotz, Xerox (minutes)
Erik Bruchez, Inventive Designers/Orbon [joined late]

* Agenda

* Community Group

Leigh Klotz: Alain sent a community group message and I responded but there is nothing in the archives. I believe it was internal-xformsusers. I'm not sure why we need the internal-xformsusers.
Steven Pemberton: It is there. https://lists.w3.org/Archives/Member/internal-xformsusers/2012Mar/0000.html
Leigh Klotz: I see. I misread the page. https://lists.w3.org/Archives/Member/internal-xformsusers/
Steven Pemberton: We need to put some text on the main wiki page. And there is a chat.
Leigh Klotz: It's #xformsusers
Steven Pemberton: We don't yet have a quorum today.

* Community Group Goals

https://lists.w3.org/Archives/Member/internal-xformsusers/2012Mar/0001.html https://lists.w3.org/Archives/Member/internal-xformsusers/2012Mar/0000.html http://lists.w3.org/Archives/Public/public-forms/2012Mar/0031.html Leigh Klotz: I have 3 goals:

Steven Pemberton: We should write a message and send it to www-forms.
Nick van: And the test suite. The commuity group is covered for copyright.

Steven Pemberton: The nice thing about using XForms+XHTML note there is that we can just put it on the wiki and we can turn that into a spec.
Leigh Klotz: And it comes with a wiki.
Nick van: Maybe we can encourage people to review modifications or additions to the spec and discuss them there.
Steven Pemberton: Yes, we can keep people updated on spec changes as they happen.

Steven Pemberton: We could maintain the list of implementations there.

Nick van: Vendors can discuss proposals there instead of on their own lists.

ACTION-1877 Steven Pemberton to send welcome message to Community Group

Steven Pemberton: And how about chair. It needn't be someone in the working group.
Leigh Klotz: The process says the community group should elect a chair.

* Device Magic


Steven Pemberton: Device Magic announced a new implementation.
Leigh Klotz: We should invite them to join the community group.
Steven Pemberton: Absolutely! It's a mobile implementation. "Data collection." Personal for one device is free.
Steven Pemberton: Android but no Symbian.

ACTION-1878 Steven Pemberton to migrate implementations list to Community group

* Quick review of completed spec changes

** Attributes that don't support AVT


Steven Pemberton: Anybody think that @type should be an AVT. No? Looks like a good list, Nick; thank you! Could you add this to the section on AVT?
Nick van: I did this throughout the spec, not in one place. I can add it.
Steven Pemberton: It is handy: all attributes are either XPath or AVT, with the exception of the following: ...
Leigh Klotz: It could be a note.

ACTION-1879 Nick Van den Bleeken to add non-normative note to AVT section listing exception attributes; they are normatively described in their individual sections

Erik Bruchez: [joins]

** Changed context child of dispatch to property


Steven Pemberton: The middle line is wrong; it says context.
Leigh Klotz: And the close tag on the third property element.
Nick van: OK
Steven Pemberton: We leave off the xf: prefix in all the examples. Thank you Nick.

* 7.9.5 Serialization as application/xml


Steven Pemberton: This is done; we're leaving as is but with a note asking for opinions.

* Custom XPath functions in XForms

** Proposal for function bodies

http://lists.w3.org/Archives/Public/public-forms/2012Mar/0019.html http://lists.w3.org/Archives/Public/public-forms/2012Mar/0029.html

** Spec updates


Nick van: This would be good to discuss: http://lists.w3.org/Archives/Public/public-forms/2012Mar/0029.html
Nick van: Erik and Philip asked that we drop the sequence element and just put XQuery, XPath, or JavaScript directly.
Leigh Klotz: And Erik proposed nested var element.
Erik Bruchez: Yes, by nesting script, var, or result elements we create our own language, as we did for actions. For actions it may make sense. But for functions it may be nicer if the body were just nicer to use the language. It's annoying that XPath 1 and XPath 2 you can use for--return, and XPath 3 has variables. So you need not have var or return. Even more so with JavaScript or XQuery. So to keep things simple, we could just have the function body be in the language.
Nick van: This would be the first place where we have an XPath expression as child text content. That would be the same in XSLT. That's a minor issue.
Nick van: The bigger issue is that we target XPath 2.0 and so writing functions without using variables is not handy.
Erik Bruchez: The first doesn't bother me as XPath is evolving. I find myself writing multi-line expressions in attributes. As XPath progresses forward and gets variables and inline functions, it becomes a scripting language. I think it makes sense to put XPath a notch under XQUery and it's OK to put XPath expressions not in attributes, for side-effect-free scripts.
Erik Bruchez: The second part is a letdown; there is a huge benefit of simplicity in the spec. Since we decided XPath 1.0 is mostly out of the way, you have full variables in XPath 2 and you can do nested for-return and as long as you're cautious with empty sequences, you can do it. It's not that we don't need variables: it's crazy to think we have an expression language without variables. But we'd be doing the same work in XPath and XQuery and JavaScript. Becuase we add variables we also have return, and that's extra area.
Nick van: In the future, if you want to create mixed content, text outside sequence could provide mixed content.
Erik Bruchez: Yes, that's a downside. But there is use even in XPath 1.0 with common-expression functions, and moreso in 2.0 and definitely in XPath 3.0, XQuery, and JavaScript. I'm not sure what others think about this simplification. I'm leaning more toward this simplification. XPath 3 is not a huge departure from XPath 2. You can hope that people would quickly move to XPath 3. So we're specifying something that's already a little bit obsolete.
Nick van: For Saxon the XPath 3.0 engine isn't available publicly yet. It will take a while in the home edition. It's in the professional edition. http://www.saxonica.com/feature-matrix.html
Erik Bruchez: So does Saxon plan to support XPath 3 in the open source version?
Nick van: I don't know.
Erik Bruchez: If there are no open-source implementations of XPath 3 then that would slow adoption. There are cases where intermediate variables are needed, but you have to jump through hoops. There's more beauty if you say the script content is the spec. It come with some things that are undesirable. It makes the functions useful. We could start this way and see if implementors need variables and could justify adding them to the spec.
Nick van: If we go with content-is-expression then we can't use constant string.
Leigh Klotz: You mean you can't use literal elements?
Nick van: You can't.
Leigh Klotz: If you use XQuery then you can.
Nick van: But for XPath the content is an XPath expression.
Leigh Klotz: But why invent our own literal-template syntax when they could use XSLT or XQuery?
Nick van: The downside is that not a lot of implementations will support it.
Leigh Klotz: Maybe we could define our own profile of XPath 2 with added variables from XPath 3 and added literal-result-element-as-stylesheet from XSLT and then call that our own language, and give it a name and use it in the type of functions, but that's a big design to do and I don't think it would fit inside the XForms Recommendation.
Nick van: That sounds reasonable.

Leigh Klotz: Is function=var*,text good enough or is it too little for the complexity it costs?
Nick van: I think either our own language or just XPath. Something that's in between isn't worth it.
Leigh Klotz: We're still talking about function/@type, though, right?
Nick van: Yes. If we remove the child element, then you can have a source attribute. Does it make sense for an XPath expression to be defined somewhere else?

Steven Pemberton: I think we need a bit more input from the group. Can you summarize the proposed spec changes?
Nick van: My last email is good. The second point fro http://lists.w3.org/Archives/Public/public-forms/2012Mar/0029.html
Steven Pemberton: I understand that this is the third change, but it's not fully crystallized out yet. We should not change this again until we decide on the final version.
Nick van: I don't mind changing it again.

Leigh Klotz: So let's say we require XPath and we allow JavaScript or XQuery, and we don't have variables in functions and XPath 2 has a kludge for varables, so if you need more, tell us why you need them and aren't using JavaScript or XQuery or XPath 3?
Steven Pemberton: What about alternate definitions?
Nick van: I did add @override so you can do that.
Steven Pemberton: OK, let's just add a note for now.
Nick van: I'll add a note about variables.

* IRC Minutes


* Meeting Ends