RE: xf:transform for XForms 1.2

Hi Philip,

I completely agree that the having the 'transformer' in the instance is much more flexible then having (only) the referencing uri solution.

I know that it is an implementers issue, but I foresee quite a challenge in knowing when the 'transformer' has changed when it is the result of an XPath expression. In most transformer engines 'compiling' the transformer to something that can be executed takes a considerable part of the total processing time, and therefore you want to cache that 'compiled' form in the engine. If you have a URI you can simply use the change date to know when the transformer is changed, but if you have a complex XPath expression this might be a challenge. On the other hand a lot of implementation already have a 'dependency' graph in the UI which is a similar problem (you can't use the dependency algorithm from the spec because it depends on manual rebuild actions). It might get also a bit more complicated if you have XPath 2.0 support in your XForms engine, but I'm not completely sure about this.

Nevertheless I think, if implementation experience proofs that it is feasible to have the transformer as a result of an XPath expression, we should support to have the transformer as a result of an XPath expression.

Regards,

Nick Van den Bleeken
R&D Manager

Phone: +32 3 821 01 70
Office Fax: +32 3 821 01 71
nick.van.den.bleeken@inventivegroup.com
http://www.inventivedesigners.com
Linked in


> -----Original Message-----
> From: public-forms-request@w3.org [mailto:public-forms-request@w3.org]
> On Behalf Of Philip Fennell
> Sent: donderdag 16 september 2010 8:37
> To: Leigh L Klotz Jr; public-forms@w3.org
> Subject: RE: xf:transform for XForms 1.2
>
> Although I made the suggestion about the resource element/attribute for
> the transform action URI, I'd much prefer to see the 'transformer' loaded
> into an instance and referenced that via a bind rather than directly
> dereferencing it.
>
> Loading the XSLT, XProc or XQuery (suitably wrapped) into an instance gives
> you, without a second thought:
>
> 1) In-line transforms
> 2) Load event handling via xforms-submit-* events
> 3) The ability to generate and/or transform transformers
> 4) Dynamic transformer URIs (xf:resource element)
> 5) Transformer validation
> 6) Constraints/events based upon transformer content
>
> Obviously the single URI attribute is very succinct but you loose an awful lot
> of potential if you go solely down that path.
>
>
> Regards
>
> Philip Fennell
> Consultant
> MarkLogic Corporation
> Mobile +44 (0) 7824 830 866
> email  Philip.Fennell@marklogic.com
> web    www.marklogic.com
>
> This e-mail and any accompanying attachments are confidential. The
> information is intended solely for the use of the individual to whom it is
> addressed. Any review, disclosure, copying, distribution, or use of this e-mail
> communication by others is strictly prohibited. If you are not the intended
> recipient, please notify us immediately by returning this message to the
> sender and delete all copies. Thank you for your cooperation.
>
>
>
>
> ________________________________________
> From: public-forms-request@w3.org [public-forms-request@w3.org] On
> Behalf Of Leigh L Klotz Jr [leigh.klotz@xerox.com]
> Sent: 15 September 2010 18:41
> To: public-forms@w3.org
> Subject: xf:transform for XForms 1.2
>
>   Claudius Teodorescu has made a proposal and has some questions.
>
> http://lists.w3.org/Archives/Public/www-forms/2010Sep/0029.html
>
>
> Leigh.
>
> --
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.
> --
>


Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--

Received on Thursday, 16 September 2010 08:08:05 UTC