W3C Forms teleconference May 25, 2011

* Present

Erik Bruchez, Orbeon
Leigh Klotz, Xerox (minutes)
Nick van den Bleeken, Inventive Designers
Philip Fennell, MarkLogic
Steven Pemberton, CWI/W3C (chair)
Uli Lissé, DreamLabs
Kurt Cagle, XMLToday

* Agenda


* Previous Minutes

* XForms: MVC in the Browser


Leigh Klotz: This is more about MVC in the browser, using XSLTForms as an example.

* Editorial Meeting

* transform function module

http://lists.w3.org/Archives/Public/public-forms/2011Apr/0018.html http://lists.w3.org/Archives/Public/public-forms/2011Apr/0019.html http://lists.w3.org/Archives/Public/public-forms/2011May/0014.html http://lists.w3.org/Archives/Public/public-forms/2011May/0015.html Recent updates from Philip Fennell: http://lists.w3.org/Archives/Public/public-forms/2011May/0021.html Recent updates from Kurt Cagle: http://lists.w3.org/Archives/Public/public-forms/2011May/0019.html And the latest from this morning: http://lists.w3.org/Archives/Public/public-forms/2011May/0024.html

Philip Fennell: I've written up more on the wiki, on Transform (general) and on the XForms Transform Function Module (spec-track). All use cases boil down to one particular action: 'apply a transform to an instance prior to doing something else', and it is how the result of that transform is piped to a destination and how the following behavior is triggered that is what actually differs. It is an optimization of a transform action; it cuts-out a lot of the intermediate rigging that you need to do so it can be thought of as more declarative. But I think we should define the full-featured transform more clearly first. I've come to the conclusion that the transformation is a close relative of submission, moreso than insert. The submission feature of XForms has some very close parallels to transform: it identifies the action to apply; it has parameters (http headers), mediatype, encoding, events for before and after, and error notifications. It strikes me that it's more like a submission than any other action such as an insert. I hate to stop progress, but should we start looking it as like a submission rather than like another action? Once we've solved the variability there we can look at the transform function.
Kurt Cagle: I see two potential use cases for transformation: a submission of content being transformed as part of the submission process, and presenting an output rendering of the content into the page itself. For instance, transform the instance into a graph and display the SVG. I'm not sure where that falls with the submission use case.
Philip Fennell: I don't think it is. When applying a transform to an instance, we talked about referencing the transform, source data, destination, parameters, mediatype, result type (text, node), and encodings. All these are already defined on submission. If the result is being picked up by an output, or if it's being sent into another instance, you've got those in submission as well.
Leigh Klotz: You might say our submission element is a special case of the generic transform.
Philip Fennell: Yes.
Kurt Cagle: Makes sense. So instead of using a server URL you use a client hash.
Philip Fennell: It makes it in line with the rest of XForms.
Kurt Cagle: It makes output still act on a reference.
Nick van: The major difference I see how it's triggered. I would expect that if it's a function the input data for the transform changes, but with submission it's by an event.
Philip Fennell: I'd like to drop the transform function as primary and understand that while it's concise... I'm not suggesting we overload submission with transform, but that we should copy that principle however we can and still have a transform action, and then ...
Kurt Cagle: You can also have transform-error.
Philip Fennell: You can still have errors: http://www.w3.org/MarkUp/Forms/wiki/Transform#Transform_data_before_displaying

<xforms:output value="serialize(transform(my-stylesheet.xsl, instance()))" mediatype="application/xhtml+xml"/>

Philip Fennell: You might have an xforms-compute-exception or my suggestion an xforms-transform-error.
Erik Bruchez: I would expect XPath error handling to look like exceptions; XQuery 3.0 has exception handling, as will every language that has functions, eventually. You can imagine that's how to handle errors in the future.
Philip Fennell: try/catch in the XPath expression
Erik Bruchez: Yes, and then it would turn into an event dispatched as compute-exception (or whatever).
Nick van: That's what I was thinking as well.
Leigh Klotz: It almost seems like the generic case is XProc rather than transform or submission.
Philip Fennell: Yes, it nicely handles the transforms and inputs and outputs.
Kurt Cagle: I think you need at least an interim xf:transform first step, with an xfproc as a downstream solution. A lot of people here like XProc but it's not clear you can implement it in client environments.
Erik Bruchez: We're trying to define an API, either complex as in Java or one function for everything as in PHP. If XSLT is the major use case, and there maybe we need a quick way for an author to do that. Behind that we can have something more generic.
Philip Fennell: Is it worth spending some time writing up the parallels between transform and submission?
Leigh Klotz: I'm convinced, but is transform like submission, submission like transform, or both like something else?
Erik Bruchez: And lots of things are like functions. A syntax with actions is going to be heavier than an XPath function. I'm not sure we could unify that from a syntax perspective?
Philip Fennell: The current transform function is very simple, but there are a lot of complexities in defining the transform. We should look at the complex case first and we might miss something and paint ourselves into a corner.
Kurt Cagle: It's a little heavier than the function but the downside is that it locks out some of the cases we're talking about. A function that doesn't work well with output is problematic: output must take a tree, for starters. The function doesn't work well for the submission case, unless you note that it's invoked as a final process based on an event.
Nick van: ...
Philip Fennell: ...
Nick van: When we started the action-or-function, discussion, the action is just the function with insert.
Philip Fennell: When we started looking at the complexities of the function, we have instances, parameters, etc. we start to work around the issues of how we define things and it doesn't seem like an integrated solution. Kurt has a valid suggestion, but it's not consistent with the rest of XForms.
Nick van: We need something for arguments, but we should be able to define transformations like with submission. Then the first argument is the name of the stylesheet and the function is the one in the definition.
Leigh Klotz: I think that's consistent with what Philip said. I pasted something like that in.
<function name="transform"><argument name="src" type="anyURI" result="instance(myresult)" type="element" /><argument name="doc" type="element" /><transform src="${src}" type="application/xml" processor="xslt" replace="instance" instance="myresult" /><instance id="myinstance" /></transform></function>

Erik Bruchez: Our language choices are poor for this: XPath, and the action language. Both are extremely limited and verbose. We're trying to work with the limitations of these two languages and it's a little ... the real issue is the languages we have at our disposal. With JavaScript it would be easier to define API and syntax. I've been thinking that we should give authors some kind of API which cleanly maps to JavaScript or other languages such as XQuery, so you can use those languages instead of XPath 1.0 or our action "language." I'm not sure we should rethink a transform function, but in our implementation when we hit the complexity barrier, with actions.
Kurt Cagle: ...
Erik Bruchez: The action language is powerful but it's terrible for complex things. It's not the big value of XForms. It's handy for simple things, but we have a number of concepts that are relevant in our XPath API as well the action language: updating instances, accessing controls, toggling cases, but all that could be exposed in an API, defined in XForms as an API, with a JavaScript binding. You still have instances, XPath as binding and constraints and MIPs, and controls, submissions, but for the more programmatic aspects...
Kurt Cagle: I don't disagree, but that sounds like a 2.0 rethink. It involves opening the box at a deep level and rethinking a lot.
Erik Bruchez: I'm not saying it's a 1.2 thing. Someone should propose something first, such as an API. XForms 1.1 has some API functions, but it's useless: rebuild, recalculate. There's no real XPath API. We're often adding functions to an XPath library which remains fairly poor compared to what people expect nowadays because people can add their own functions. We don't have any re-use in that area.
Steven Pemberton: I hear what you're saying and I think you're right about new functions, but the central point of this agenda item is integrating transform into XForms. What you're saying is useful and we should make it a separate point of discussion and focus on transform now. Philip has a good analysis of the situation.
Erik Bruchez: Concretely, it tells me that I'm less in favor of actions as I think actions are dead ends.
Steven Pemberton: I think we'd already agreed on that.
Erik Bruchez: I think we should decide more on the XPath front. In XPath 3 or XQuery 3 it would be easier. For now we have to make do with XPath 1.0 but it's pretty sad.
Steven Pemberton: I thought we had resolved to use XPath 2.0.
Erik Bruchez: Do we still expose the function through XPath 1.0?
Philip Fennell: That would be unavoidable wouldn't it given that state of XSLT?
Leigh Klotz: XSLTForms doesn't use the underlying XSLT engine in the browser.
Kurt Cagle: And Saxon-CE. Orbeon uses XPath 2.0
Nick van: And betterForms and chiba.
Kurt Cagle: Do we have a way of being able to build in an extension function into XPath 2.0 implementations? Is this something that should be a formal requirement? I don't think we can do it from XForms itself but it's probably worth studying the XSLT functions.
Leigh Klotz: You can always use http://bellard.org/jslinux/ and write the code in Linux.
Steven Pemberton: So there's no argument that you can't do it in JavaScript.
Steven Pemberton: http://www.seneca.nl/pub/Vacatures/Stage-Xforms-web-formulieren-developer.html "Seneca BV implementeert momenteel de XForms W3C standaard in het CMS Smartsite iXperion.
Philip Fennell: So I will write up the submission-like element and show how to use it from a function.
Leigh Klotz: Let's not write up the function. How we invoke an action, or if as Erik says a script, is a separate problem as Steven said.

ACTION-1803 Philip Fennell to write up parallels between transform and submission, and leave function-that-invokes-transform as a separate problem.

* Schematron validation (via transform)

http://lists.w3.org/Archives/Public/www-forms/2011May/0001.html http://lists.w3.org/Archives/Public/www-forms/2011May/0002.html

Philip Fennell: I hope to have this done in the next couple weeks.

* IRC Minutes


* Meeting Ends