W3C Forms teleconference February 20, 2008

* Present

John Boyer, IBM (chair)
Leigh Klotz, Xerox (minutes)
Erik Bruchez, Orbeon
Roger Pérez, Satec
Rafael Benito, Satec
Susan Borgrink, Progeny Systems
Keith Wells, IBM
Uli Lissé, DreamLabs
Joern Turner, DreamLabs
Steven Pemberton, CWI/W3C
Nick van den Bleeken, Inventive Designers
Doug Schepers, W3C
Mark Birbeck, x-port.net

* Agenda


* Previous minutes

* Reports

Leigh Klotz: I am not done with the newsletter. I did respond to XML Core on PER 5, and have been working on the ITS issue.
John Boyer: I see you also responded to the Access Control.
Leigh Klotz: I'll try to work on the newsletter today.

* XForms 1.1 Context function and attribute


Erik Bruchez: It wasn't as clear as it could be but I don't feel a change is needed for XForms 1.1.

* Non-selected case and non-relevant group


* XForms 1.1 omits Target, Bubbles, Cancelable, and Context Info in 11.2


John Boyer: I dropped some text.

Action 2008-02-20.1: John Boyer to fix missing text in http://lists.w3.org/Archives/Public/www-forms-editor/2008Jan/0002.html

* The xforms-submit Event - concurrent submissions


John Boyer: He seems to think that it says you can't have any submissions concurrently.
Erik Bruchez: It's per submission.
John Boyer: He says the wording says that all subsequent ones submit error, which is not what we mean.
Erik Bruchez: I'm not sure why he thinks it is unclear; it says for a particular XForms submission.
John Boyer: It's the second sentence, "From the start of the default action of xforms-submit" which is a separate sentence. We could make it clear which submission.
Erik Bruchez: For the given submission.
John Boyer: If there are no objections, I'll throw together a patch for XForms 1.1 CR; it's a minor clarification.

Action 2008-02-20.2: John Boyer to clarify text for http://lists.w3.org/Archives/Public/www-forms-editor/2008Jan/0001.html as a minor editorial change for XForms 1.1 CR.

* CSS3 and XForms 1.1 CR


John Boyer: We've been asked to look at the CSS3 Namespaces module. Leigh has the action to update the CSS in our Appendix G. I wrote to Bert Bos and said that we have these TBDs in our document and asked if they could take them on. He felt that they were already in CSS3 and said we should investigate and update the appendix. According to Bert, the UI and Selectors modules are at least in CR and we could normatively reference those, though it is an informative appendix. If they don't have the features, providing that as feedback would be useful.
John Boyer: Leigh would you take on the additional action item update Appendix G?
Leigh Klotz: Sure.

Action 2008-02-20.3: Leigh Klotz to update Appendix G to match current CR version http://lists.w3.org/Archives/Public/public-forms/2008Feb/0067.html

* Reach consensus on scope/requirements of XForms 1.2


John Boyer: We had a set of patterns from the F2F. The ease-of-authoring pattern wasn't quite right, but we were more getting at things that made it easier for today's web application authors to consume XForms. We had that bucket. Then floating up into 1.2 are user interface patterns. We need to come up with new vocabulary to come up with larger constructs out of sets of XForms controls together; for example, not just repeat, but providing column headers, row headers, triggers for insertion and deletion of rows, whether the repeat should be allowed to be empty, etc. Things that would simplify the authoring of the full table concept. With patterns, this got moved to 1.2 from 2.0.
John Boyer: Also we have a bug fix on model-based switch. In XForms 1.1 and below, it's hard to do. If you keep the state in the model, you can't enforce that it's always running effectively and you can't use a switch.
John Boyer: It's also difficult to have a default action for the page, with enter for example. At the F2F we discovered that didn't seem to be something that was well laid-out in HTML4 forms anyway; enter seems to work there by depending on the simplicity of the page, and they don't have a similar construct; it is just first submit in build order, and it does different things in different orders. We have an equivalent level using DOMActivate in current XForms 1.0; that was new to me.
John Boyer: Under composition patterns, we have nested and referenced models, getting models from elsewhere. Custom XPath function, a bit of a stretch in composition. It would help today's web application authors; implementation in JavaScript would help today's authors. Multiple MIPs on the same node would have to be rationalized. That's in composition patterns because of multiple models assigning rules to the same node.

John Boyer: I think we should cut down on the scope of XForms 1.2 to the things necessary for achieving the charter and focus on the 1.2 modularization; once we have that modularization in hand, as we go forward into XForms 20, we can incrementally upgrade these modules without a lot of trouble. On the mailing list, I didn't see a lot of dissenting opinion, but maybe we should open it up.
Leigh Klotz: We have to make sure we get the modules right to have places to plug things in.
John Boyer: Well, some patterns such as wizard go in container module. So there's group/switch/repeat containers.
Leigh Klotz: I was thinking about the function extensibility, which seems hard to design without putting it in.
John Boyer: That review is in this link: http://lists.w3.org/Archives/Public/public-forms/2008Feb/0055.html
John Boyer: If you scroll down a bit, you'll see the proposal that we drop the notion of patterns and streamline for Web Application Authors. I propose that we drop most of the composition, except for the functions. I think we can drop the rest. We need to keep the model-based switch.
Leigh Klotz: So you're proposing we keep custom XPath functions? That's fine; I just objected to doing the interface definition but postponing the implementation.
John Boyer: The JavaScript custom functions would be nice.
Leigh Klotz: I still like XQuery as it's upward compatible from XPath 2.0; I can see it fitting into modularization.
John Boyer: I wasn't talking about JavaScript as the expression language. I'm talking about functions such as decimal-string that could be written, functions for calculation, to give us a shield against needing new functions in each release, even for XPath 1.0 expressions. The current web author reaction would be to write sumproduct in JavaScript, and we would offer a way to connect it.
John Boyer: The modularization of the expression language itself is in XForms 2.0, along with schema modularization.
Leigh Klotz: I thought you were pulling that from XForms 2.0, not just the custom function.
John Boyer: It should also be possible to define functions in terms of XForms actions, but JavaScript could be a reasonable alternative. Custom functions have to show up in the functions attribute of the model element, and the XForms processor has to make sure that's available somehow.

Leigh Klotz: I thought that we added @functions since we had no way to put functions in another namespace because we got comments from XPath about originally using namespaces.
John Boyer: I think it's the other way; we got comments about using prefixes and took them out.
Erik Bruchez: Yes, every XPath processor supports it.
John Boyer: The function attribute declares functions that were needed and not supported by XForms already. Early on, my processor included the XForms 1.1 functions power and current, which are not strictly-speaking XForms 1.0 functions. So I include functions="power current" in forms, and any other processor knows up from if it doesn't have them.
Leigh Klotz: If you look at XSLT they declare the extensions namespace.
John Boyer: The functions attribute lets you declare it up front and not run the application, rather than at runtime.
Leigh Klotz: You can statically analyze it. If you restrict extension functions to have prefixes, then you can even ignore functions that don't have prefixes. Or are we going to allow functions without prefixes?
John Boyer: Yes, all will be in some namespace, we said at the F2F. http://www.w3.org/MarkUp/Forms/wiki/Custom_XPath_functions So the name is defined in the local-function namespace and it has to be in the local: namespace.
Erik Bruchez: Unless I'm wrong, in XSLT 2.0, you have to use a QName for the function name. I'm not sure should do that.
Leigh Klotz: Doesn't XQuery have the same feature; you define without qnames and invoke with local:
Erik Bruchez: We'll have to check the spec.
Susan Borgrink: [irc] yes that is correct
John Boyer: We should ask Mark Birbeck as he says this is current practice.
Erik Bruchez: I think we should follow XSLT 2.0. http://www.w3.org/TR/xslt20/#stylesheet-functions
Leigh Klotz: XQuery does appear to use a prefix on the definition but I don't see how it works as there is no declaration. http://www.ibm.com/developerworks/library/x-xqueryrss/#N10181
Erik Bruchez: We should follow XSLT 2.0 because we're defining XPath functions.
John Boyer: We should find out from Mark why he thinks we don't need the namespace.
Leigh Klotz: Is there a way in this proposal to define a function in JavaScript and associate it with a namespace?
John Boyer: I proposed a way, using function and implementation methods.
Susan Borgrink: I'm assuming you code it in Java. If you put it in Java, your functions are in one package. You have to access it via that package.
Leigh Klotz: If you look at a function package called "math" described at exforms.org, for example, I don't see a way to implement it in script in one XForms processor, then in Java in another, and have them both be callable as math:foo.
Susan Borgrink: I'll have to think about that.
Erik Bruchez: You can have libraries this way.
Leigh Klotz: What's the mechanism to associate the namespace with the function?
Erik Bruchez: Associate the namespace prefix with the URI. xmlns:math="java:org.apache.utils.MyMathClass" select="math:power()"
Nick van: [irc] http://www-128.ibm.com/developerworks/library/x-xalanextensions.html
Nick van: It is quite the standard in XSLT land.
Leigh Klotz: This tightly ties the namespace declaration to the implementation and I don't see how it can work in both Saxon and Xalan.
Erik Bruchez: I'm not sure you can.
Nick van: Xalan and Saxon use the same syntax. You can use the same stylesheet in both, but both implementations are in Java.
Leigh Klotz: I don't see how this can work as it's bound to the implementation language.
Nick van: My link uses the old Xalan; there's one used by both Xalan and Saxon.
John Boyer: How can we support the notion that in XForms implementation A it comes from Java and in B it comes from JavaScript.
Erik Bruchez: So how do we do function libraries? You have to be able to support a namespace that identifies a library scheme, or use any URI and an implementation-defined mechanism to bind to a library.
John Boyer: One thing we talked about was multiple implementations. The idea might be that the function had multiple implementations, and as long as one was viable, it would work. You could indicate one from Java, and another from JavaScript, on a different processor. The interpretation of the function would look at the first, Java, then the next, JavaScript, then one in XForms actions, probably less efficient, but portable. If you can't, then you would get an error.
Erik Bruchez: I'm not sure we have to do that kind of thing. It seems a lot of work to define bindings to Java and JavaScript.
Leigh Klotz: I think it's important, as a user of XForms, and not a vendor. This proposal causes vendor-lock in and we should be careful.
Erik Bruchez: It does allow portable definitions using XForms; how many language bindings do we have to support?
John Boyer: Leigh wants access to the extension functions either way, with multiple implementation statements, on both Vendor A and Vendor B's processor.
Erik Bruchez: I'm not necessarily against standardizing the way to import a Java or JavaScript method as done in Saxon and Xalan. But I was under the impression that much more than that would be needed. Would you want to write the body of the function in the form? That would be complicated.
John Boyer: I hope not; just referring to them externally would be preferable. We could just separate out the function from the name: <implementation name="java:org.apache.utils.MyMathClass"...<implementation name="javascript:foo" Nick:[irc] <func:script implements-prefix = ncname language = qname-and-not-ncname src = uri-reference archive = uri-reference /<
Nick van: [irc] A Java class: src="java:com.example.datestuff.DateRoutines"
Nick van: [irc] An ECMAScript library: src="http://example.org/somecode.js"

Erik Bruchez: XSLT doesn't specify how to invoke Java functions, but we do it in our processor because we use Saxon. Otherwise each processor has to implement dozens of seemingly random functions.
John Boyer: No particular XForms processor would be required to implement any engine. But if you do have access to say, a Java engine, a webapp author would be able to cover differences by having the custom functions available. I guess you're saying that they might have made it available in different ways.
Nick van: In exslt, they have two different concepts: you can define a function, and they have the possibility to bind a qname to a "script" and there you can specify the qname, the language, and the source URI that refers to the implementation of the function. You can point to Java, or JavaScript, for example.
John Boyer: I think you're the guy with the ball to mature this; I realize now that we're about seven minutes away from concluding. I'd like to take it up a level and come up with the next version of what's here.

The larger question is, are we going to go with this overall proposal to be "streamlining for webapp authors." The connection to the custom XPath functions is that webapp authors would be likely to say JavaScript things, not just native XForms things. So the requirement from an XForms 1.2 perspective is that there be way for the webapp author to glue them in.

Nick van: For the record: Erik has the action to write up 'Custom XPath functions''
Erik Bruchez: Yes, I did. But if Nick wants to take it over...
Nick van: I have a lot of other actions.
John Boyer: Erik, you seem like the perfect guy, if you can, to make something more of this; you don't have to stick with what's written, and it sounds like there might be some additional questions. For this to be in XForms 1.2, I would have it if the only way to do implementations would be JavaScript. I'm in favor of having XForms functions as a way to work across all implementations; maybe that's the limit in XForms 1.2. Maybe we offer the ability to do it in JavaScript as an alternative.

John Boyer: The proposal is that we limit XForms 1.2 to the things that are in that mail: http://lists.w3.org/Archives/Public/public-forms/2008Feb/0055.html Does anybody on the phone feel they want to think more?
Leigh Klotz: I think we need to cut back, there's no question, but I think we need to retain some fluidity, especially this early.
John Boyer: I'd like to get the requirements document out soon, and reach that minimum bar.
Nick van: [irc] I can go with it but I think I would prefer to add 'Same model item property on the same node ' but this can be under the hood of Add model item properties to UI level
Nick van: [irc] so it is fine for me
John Boyer: Yes, that and the external model may not be that hard. They might not have to be in the first public working draft or the requirements. We need some latitude.
John Boyer: So are there any objections to limiting the scope of the requirements document for 1.2 to http://lists.w3.org/Archives/Public/public-forms/2008Feb/0055.html I can put an optional bucket in the wiki so we can work on it for 1.2 but it doesn't have to show up in the first initial public documents. Does that make sense?
Erik Bruchez: [irc] fine with me to limit the scope of 1.2
Nick van: [irc] fine for me
Susan Borgrink: [irc] ok for me

John Boyer: Seems to be a wrap. And welcome back Susan!

Resolution 2008-02-20.1: We limit XForms 1.2 requirements to http://lists.w3.org/Archives/Public/public-forms/2008Feb/0055.html and list optional items in the wiki to be done after first draft, if possible.

* IRC Minutes


* Meeting Ends