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
• Editorial Meeting
• transform function module
• Schematron validation (via transform)
• IRC Minutes
• Meeting Ends

* Previous Minutes

• http://www.w3.org/MarkUp/Forms/wiki/Minutes

• http://lists.w3.org/Archives/Public/public-forms/2011May/0018.html

* XForms: MVC in the Browser

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

* Editorial Meeting

• Editorial meeting in June/July Amsterdam?

• Editorial meeting August 29-31, 2011, in SF Bay Area.
  Steven Pemberton: Nick and I are planning dates for the Amsterdam meeting.
  Nick van: I think I can attend the SB Bay Area one as well.
  Steven Pemberton: So it's still an editorial meeting but we should encourage people to come.
  Kurt Cagle: I may be on that coast by then.

* transform function module

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"/>

<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>

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)

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

* IRC Minutes

* Meeting Ends