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 12:45:20 UTC