RE: About XForms 1.2 "The XForms Transform Function Module"

Erik,

Another thought, or two, had occurred to me recently, are there going to be any events associated with the transformation process:

Notifications -	xforms-transform-done
Errors -		xforms-transform-error

and in the case of errors, what about event properties that allows access to the error type, message, etc.

In the case of XSLT we might want to pick-up on events triggered by xsl:message terminate="yes" instructions and what could/should we do with non-terminating messages. We don't have a console, in the traditional sense, but what about another notification:

xforms-transform-message


Currently we are restricting ourselves to XSLT 1.0 with the transform function, or at least that's my impression, but further down the line, if we get into XSLT 2.0 then we'll need to address how we handle multiple result documents (xsl:result-document rather than a sequence as a result) and how, may be from within the transform, we bind those outputs to xf:instances. I feel it's probably unlikely that someone would got to that much complexity for an XForms based transformation but I'm sure someone will try it and a reason to do it. That also applies to XProc too.


Regards

Philip Fennell
Consultant
MarkLogic Corporation

One Kingdom Street
Paddington Central
London W2 6BD
United Kingdom

Mobile: +44 (0) 7824 830 866 
Tel:    +44 (0) 203 402 3619

email  Philip.Fennell@marklogic.com
web    www.marklogic.com





-----Original Message-----
From: public-forms-request@w3.org [mailto:public-forms-request@w3.org] On Behalf Of Philip Fennell
Sent: Thursday, April 28, 2011 9:14 AM
To: Erik Bruchez; Forms WG
Subject: RE: About XForms 1.2 "The XForms Transform Function Module"

Erik,

> I don't remember if we discussed in the working group supporting
> storing the transform (stylesheet) in an instance

Neither do I, it was at least a year ago when we last discussed this.


> In most use cases, I would imagine the transform to be stored in its
> own instance and rarely modified

Yes, although you may have a scenario where you have an instance for a transform but the choice of which transform is context sensitive and therefore loaded on demand. I guess the context sensitivity may drive you to just use the transform(uri, node?) signature of the function if the transform URI is embedded in your source document. Some form of XSLT transform editor written in XForms would be an interesting use-case for transform(node, node?) as would a Schematron schema editor that used the reference implementation XSLT transforms to compile the schema and apply it to the source instance.

I'm still planning on having a play with XForms + Schematron and this has given me another nudge to put it higher up my to-do list. Thanks :-)


Regards

Philip Fennell
Consultant
MarkLogic Corporation

One Kingdom Street
Paddington Central
London W2 6BD
United Kingdom

Mobile: +44 (0) 7824 830 866 
Tel:    +44 (0) 203 402 3619

email  Philip.Fennell@marklogic.com
web    www.marklogic.com




 
-----Original Message-----
From: public-forms-request@w3.org [mailto:public-forms-request@w3.org] On Behalf Of Erik Bruchez
Sent: Wednesday, April 27, 2011 6:53 PM
To: Forms WG
Subject: About XForms 1.2 "The XForms Transform Function Module"

All,

I was quickly going through this document:

http://www.w3.org/MarkUp/Forms/wiki/The_XForms_Transform_Function_Module

I don't remember if we discussed in the working group supporting
storing the transform (stylesheet) in an instance in addition, in
other words to also allow:

Object transform(node, node?)

where the first parameter points to the transform.

The same type of dependency tracking that can be used for the input of
the transformation can also be used to detect whether the stylesheet
itself has changed.

In most use cases, I would imagine the transform to be stored in its
own instance and rarely modified, therefore allowing an implementation
to cache the compiled transform efficiently.

-Erik

Received on Wednesday, 11 May 2011 06:19:44 UTC