W3C Forms teleconference April 21, 2010

* Present

Erik Bruchez, Orbeon
Leigh Klotz, Xerox
Nick van den Bleeken, Inventive Designers
Philip Fennell, MarkLogic
Steven Pemberton, CWI/W3C
John Boyer, IBM
Charlie Wiecha, IBM
Uli Lissé, DreamLabs

* Agenda


* Previous Minutes

* Upcoming telecons

Next is April 28th; Steven is out the next two weeks after that.

Steven Pemberton: I will be attending the Model-Based User Interfaces Workshop in Rome.

* Rechartering


Steven Pemberton: I need to send a note responding to the comment we received during the AC vote. We hope to hear something today or tomorrow.

* Action Item Review


Steven Pemberton: Does anyone want to report?

* Lyons Meeting details

Steven Pemberton: We've got the dates of the week but I haven't heard which two days we will have. We did ask for more days.
Leigh Klotz: I'll report back to the XML-CG call.

* model/@src use cases

http://lists.w3.org/Archives/Public/public-forms/2010Apr/0003.html http://lists.w3.org/Archives/Public/public-forms/2010Apr/0004.html http://lists.w3.org/Archives/Public/public-forms/2010Apr/0005.html Continue discussion from last week http://lists.w3.org/Archives/Public/public-forms/2010Apr/0017.html http://lists.w3.org/Archives/Public/public-forms/2010Apr/0018.html http://lists.w3.org/Archives/Public/public-forms/2010Apr/0019.html http://lists.w3.org/Archives/Public/public-forms/2010Apr/0020.html http://lists.w3.org/Archives/Public/public-forms/2010Apr/0021.html

Steven Pemberton: Can someone summarize this?
John Boyer: We're trying to see if model/@src gives appreciably more power than what we have now or something like xinclude. Erik and I did our report on what we are doing. Erik uses xinclude and XBL2. I use "FormParts," which is an injection. In XBL and FormParts, a key issue is that the IDs are resolved somehow, and that's a key part of how we get more power than XInclude.
Steven Pemberton: Resolved means change to avoid clashes?
John Boyer: In some way, fixed up at design-time or run-time to make sure that IDs across documents don't cause a problem. Doing @src or our own version of import doesn't make sense over XInclude unless we fix that problem.
Charlie Wiecha: In addition to something over xinclude fixup, there's also multiple injection points (UI, model) that would be useful.
John Boyer: Design-time Form Parts does two injections: one to the model and one to a specified point in the model. For the model, there isn't need for a resolution within the model.
Leigh Klotz: I guess for document-order in the model we have only the first instance.
Philip Fennell: Anything you inject would have to have its own ID.
John Boyer: There are possibly subtleties about event handler action ordering but I don't think people are depending on that. For runtime, the composite control might fit in the UI layer, and would contain UI and Model content, and its model wou have to communicate with the containing-document's model. So it's the runtime analog of not caring where it goes in the model.
Leigh Klotz: One of our engineers, Julie Craig, has implemented a deponent XBL2 processor, following on the fuller experience of Erik with XBL2. It took about half a day and works nicely, at least so far. I'll report back if there are issues.
Charlie Wiecha: Do you do ID fixup?
Leigh Klotz: You let the user write parameters and it just works. The form author knows the document and knows the binding points.
Charlie Wiecha: How about using XSLT gensym for creating ID nodes?
John Boyer: That can be a problem for documents.
John Boyer: Leigh's suggestion may or may not work at the moment for this but I think these problems can be solved.
Steven Pemberton: How about an instance and another department produces bind/@id for you?
Nick van: Then you can use XInclude. It's your API you are defining.
Steven Pemberton: As long as nobody clashes on IDs.
Steven Pemberton: So what are next steps?
Leigh Klotz: I'll write up the work we've done and I think Steven should say whether he still thinks model/@src or import is necessary, or if there are other use cases that aren't solved and we want to look at into it.
John Boyer: Something over xinclude you mean?
Leigh Klotz: Yes or an equivalent inclusion, server-side.
Steven Pemberton: I'd like to have something interoperable so you could how to package models.
John Boyer: It's a little like XML Events; not in the XForms namespace but you need to do them.
Leigh Klotz: We should review the XML Processing model for XInclude.

Action 2010-04-21.1: Leigh Klotz to describe deponent XBL2 used for XForms macros.

Action 2010-04-21.2: Steven Pemberton to describe use cases for inclusion not handle by XInclude or deponent XBL2.

* XSLT Extension Function


Nick van: As we discussed at the F2F, a function for doing xslt() would be a nice thing to have. Claudius came back with an implementation and there was a question about the stylesheet, which was just a URI. I also pointed out it was supported in other implementations as a node, or in the instance. Also Saxon offers a compile and an execute, for performance reasons. If you have variables, you can keep the compiled version around. With URI only, you can cache it, but if you have the stylesheet in your instance data, it's hard to cache.
Leigh Klotz: I also suggested privately that he use fragment URIs for id references in the host document.
John Boyer: Isn't this a rather large addition to XForms?
Leigh Klotz: It's community feedback and possibly an extension function. At the F2F we asked for him to propose a function instead of an action.
Nick van: It's not a big deal to add to Java-based implementations. It's probably harder to implement on small devices.
Leigh Klotz: It could be very popular, as it would be easy in Orbeon, BetterForm, XSLTForms (already done), and Ubiquity. So I think it's in our interest is to make sure that processing model doesn't get broken and I think we need to provide the group's expertise.
John Boyer: Would this be an optional feature?
Leigh Klotz: Or maybe just an extension module we publish.

John Boyer: What's the return value?
Nick van: A node.
John Boyer: But it's not in an instance.
Nick van: Neither is event context.
Erik Bruchez: Or the XPath 2.0 doc function or node creation functions.
John Boyer: So we have to deal with it. An calculate would have to deal with it. If you put this in a ref it would run often.
Leigh Klotz: You mean in a bind calculate?
John Boyer: No, a bind ref (not nodeset).
Erik Bruchez: We have a function that returns whether a node is in an instance.
Leigh Klotz: So what happens when you use bind on one?
Erik Bruchez: Nothing special, I think. We set MIP properties but not much happens.

John Boyer: I think about input/@ref="xslt()" or @ref="create-node()".
Erik Bruchez: We used that trick for repeat, for example iterating from 1 to 10. The problem was that at every refresh, all iterations were re-created. It worked, but it wasn't efficient. We changed to support repeat iterating over atomic values in XPath 2.0, so we do 'repeat ref="1 to 10"' as an extension. So you are right, it can have funny implications. We could say it's not allowed, or we could say that if you do it, you could have unusual consequences.
Steven Pemberton: Possibly it is non-interoperable?
Leigh Klotz: I think the slow refresh turned out from the definition.
John Boyer: Or there may be some deeper issues we should have already figured out to avoid support calls.
Steven Pemberton: This is an eye-opener for me on the design process and cost.

Steven Pemberton: So back to the xslt() issue. What do we do?
Leigh Klotz: We point out the input ref and the bind nodeset (ref) questions and suggest the repeat use case might be slow, due to experience.
John Boyer: He pointed out you suggested submission ref.
Leigh Klotz: submission/@ref=xslt() submits the result of the transform.
Steven Pemberton: He also wants it during the form filling.
John Boyer: The action version seems to have clearer processing as the data is always in an instance.
Nick van: But the submission/@ref=xslt() case is many, many steps.
John Boyer: submission/@ref="instance(xslted-output) and an event hanlder.
Nick van: There are a couple of extra actions and an extra instance.
John Boyer: One instance element and one event handler.
Nick van: A second action to void the instance to reduce memory.
John Boyer: Assuming you throw away the data once the submission is completed.
Nick van: It goes away.
John Boyer: It's syntactically easier, but it introduces problems elsewhere.
Nick van: As Erik pointed out, and I said in email, the attribute() creation function is handy. We have the same problem with the element() function.
John Boyer: That's true.
Nick van: We need to see how much it is used; if it's rare, we don't have to make it easy.
John Boyer: I thought the node creation functions would be specific about where they could be used. Maybe we need to say the same about xslt(). We've had functions that produce errors in certain places. I.e., a binding exception in a UI binding.
Leigh Klotz: How about in a predicate of a UI binding? The data is never seen, but there's still the runtime problems.
Nick van: The runtime refresh.
Leigh Klotz: If it has no side effects?
John Boyer: If you use it in a predicate, you'd have to collect additional nodes used out of thin air and sticking them in dependency lists. So the nodes could hang around forever.
Nick van: ...
Leigh Klotz: You can't examine the XSLT for nodes because it's Turing complete.
John Boyer: We can track what it returns. In general, functions should operate only over their parameters. The node creation functions have that property. All that gets tracked is the parameters and the results. Inside is a black box.
Steven Pemberton: Where do we go?
John Boyer: The xslt() function is more sophisticated than the element creation functions. You can achieve the same effect with the action but it's wordier.
Nick van: I think it depends on where you allow the function and it's much easier.
Steven Pemberton: So it brings concomitant dangers.
Leigh Klotz: Or you can say you cannot use it in binding expressions.
John Boyer: UI or model bindings. Only used in submission or action.
Leigh Klotz: How about repeat?
John Boyer: That's more problematic.
Steven Pemberton: What do we do next?
Leigh Klotz: We asked Claudius for the function, and now we see problems. We should decide if we want to pursue it, or if we want to recommend going back to the action.
Steven Pemberton: So it's our first agenda item for next week.

* IRC Minutes


* Meeting Ends