RE: New XPath extension function called xslt()

Uli,
I believe we should do more of our work in the style of exforms, whether it is published by W3C or outside W3C.
I don’t see much of a difference technically.
Leigh. 

-----Original Message-----
From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On Behalf Of Ulrich Nicolas Lissé
Sent: Wednesday, May 05, 2010 5:45 AM
To: Claudius Teodorescu
Cc: Forms WG
Subject: Re: New XPath extension function called xslt()

Dear Group,

I'm too in favor of a transform action instead of a xslt() function for the following reasons:

1. Such an action would have clearly defined semantics wrt model updates. The dependency problem imposed by an function simply does not exist for an action.

2. It is not true that a transform action would duplicate existing insert functionality. First, a carefully designed transform action would not be limited to XSLT, but could also employ other technologies capable of transforming XML in wider sense (XProc, XQuery). Second, the insert action is overly complex and generic. IIRC, there had been proposals to build simpler actions for specific use cases like copy.

3. I doubt that it's easier for authors to use the function because they usually don't care for side effects. It would be very hard for them to track down dependency problems caused by such a function. Also, having an action triggered by events fits much better into the declarative application model of XForms.

4. Use cases like using a xslt() function in binding expressions or MIPs would not be directly feasible with an action. However, this is not to blame on the action. Seems like the XForms processing model could use some more events ;)

5. The argument (heared at the last telecon) that an xslt() function would fit better to XSLT's functional nature doesn't hold. Just because the language used for a transformation is a functional one doesn't necessarily mean that an invocation of such a transformation is functional too. Obviously it isn't --it has side effects.

6. Last but not least implementers could be encouraged to provide xslt() as an extension function. Maybe it would be a candidate for EXForms. But I don't see a need to specifiy that as part of the XForms Spec.

Regards,
Uli.

On 05.05.10 11:37, Claudius Teodorescu wrote:
> Hi, all,
> 
> First of all, thank you for paying attention to this proposal and for 
> sharing your opinions about it. All these opinions are very 
> instructive and reveal different facets of the discussed topic both 
> from conceptual point of view and from practical usage in real-world web applications.
> 
> I would like to share my comments, too.
> 
> So, I maintain my initial opinion about an xslt action for the 
> following
> reasons:
> 
> 1. When using xslt as a function, the syntax is by far more simple. 
> But, conceptually speaking, an XSL transformation has nothing to do 
> with XPath functions. I consider that, within XForms scope, it is an 
> action, just like the other XForms actions (setvalue, insert, delete, etc.).
> 
> 2. Considering xslt as an action, one can avoid all the "problems"
> caused by "dependencies" (as were mentioned above).
> 
> 3. Such xslt action can be easily be used, wrapped in an action 
> element, to process data when "xforms-submit" event is triggered, just 
> like other actions we are doing right now before submissions in our 
> webapps. It can also be used, wrapped in an action element, to process 
> data when "xforms-value-changed" event is triggered, in order to 
> update an UI subform. It can receive @if, @while. Or it can be wrapped 
> by an action element acting as handler called by a listener, according to XML Events.
> 
> 
> Claudius Teodorescu
> http://kuberam.ro

> 
> 


--
Ulrich Nicolas Lissé

Received on Wednesday, 5 May 2010 17:14:53 UTC