Re: New XPath extension function called xslt(), versus XSLT as an action

One of the challenges we have with making the xslt transformation 
available via a function, rather than an action, is that functions can be 
called in XPaths that are in places where we expected the XForms 
processing model to keep up with "dependencies" and automatically update 
in response to changes.

For this reason, we generally expect that extension XPath functions will 
act like all other XPath functions in that they generally operate over 
their parameters and produce results such that we can track whether or not 
the function must be called again by looking only at nodes used to produce 
their parameters and nodes returned by the function, in the case of a 
nodeset result.

Granted, a code implementation can technically do whatever it wants, 
access whatever it wants, etc., but true *functions* don't do that, i.e. 
the definition of a function is one where we say that a result is a 
function of such and such parameters.  We have a couple of functions, like 
now() and random(), that we just accept won't be called repeatedly except 
in response to other external conditions, but these are edge case 
functions and indeed we have caught flak for them in last call review 
because they aren't real functions.

This xslt transformation as a function is the same in spades.  It is 
better as an action because it is easier to say that it happens at a 
moment in time in response to external events. 

Your case of using it in conjunction with an output is really no different 
than using it in with a submission.  It is *easier* to just call a 
function in a @ref or @value attribute, but it is still possible to call 
an action that produces the XSLT result into a node of data and then bind 
call upon that data node in an @ref or @value.

By comparison, with xslt() as a function, there is no realistic way to 
determine when to invoke the function again when something changes that 
would correspond to a change of the xslt ouptut.  On the one hand, we 
could just "live with it" as we do for now() and random(), but on the 
other hand those two functions are very obvious in their need to be 
surrounded by external conditions, whereas form authors might more 
reasonably expect the xslt() function to track dependencies, and our 
functions just don't do that.  Still, the form authors won't understand or 
necessarily find it reasonable, at which point we still get flak for a 
language feature (an xslt() function) that does not work very well in 
combination with other language features (like automatic updates of 
display based on UI bindings, or automatic recalculation if xslt were 
called in a bind calculate).

For what it's worth, the working group did discuss this issue further at 
the last telecon, and we also have it on the agenda for next week to make 
some kind of decision about whether xslt() as a function is a good thing 
or a bad thing, and if it is a good thing, then what limitations or advice 
can we give to help mitigate confusion in the form author community over 
what is supposed to work and what is not supposed to work.  E.g. if we can 
characterize what is not supposed to work and make it cause an exception, 
then it avoids things sometimes working and sometimes breaking and the 
form author not understanding why it isn't always working.  The downside 
of this idea is that I would have thought calling xslt() from a UI binding 
(like @value) would be one of those places where we would have called for 
an xforms-binding-exception.  So, obviously, it's all still up in the air. 


Cheers,
John M. Boyer, Ph.D.
STSM, Lotus Forms
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw





From:
COUTHURES Alain <alain.couthures@agencexml.com>
To:
claud108 <claud108@yahoo.com>
Cc:
www-forms@w3.org
Date:
04/23/2010 10:07 AM
Subject:
Re: New XPath extension function called xslt()



Hi,

Sorry for the delay about this topic.

Using XSLT 1.0 a lot in different environements, I'm used to 
transformation functions returning text whether it's serialized X(HT)ML, 
not well-formed HTML, CSV or just unformatted text.

XSLT can be useful for XForms in different situations, the two most 
obvious for me being for output and for submission. In both cases, 
parsing is not required because "output" control cannot reference a 
subtree but an element with a text node and because submission has to 
send a serialized instance, of course.

For "output" control, this could be something like 
output/@value="xslt(....)". Having a doc() function can solve situations 
where the stylesheet isn't in an instance.

I also think that a serialize() function is required for use in output 
control, at least, to render an instance according to a media-type. I 
have already defined this function to render SVG images in instance with 
XSLTForms.

About parsing, something similar to "setvalue" action could be added, a 
"parse" action. Whether the document element should replace the 
referenced node or whether it should be dropped or just kept should be 
considered...

With this minimal set of extra items, a lot of powerful processing can 
be done!

Thank you for sharing your point of views!

-Alain Couthures
http://www.agencexml.com

> Hi all,
>
> I have made some extension for XSLTForms (see 
> http://extxsltforms.sourceforge.net here ).
>
> Among these extensions, I've an xslt action, which performs a xsl
> transformation of a nodeset (part of a data instance), by using an 
external
> XSL stylesheet, and inserts the resulting nodeset in a data instance 
(see 
> 
http://extxsltforms.sourceforge.net/sitKubera/examples/xslt_action/test_xslt_action.xml

> here ).
>
> After analyzing this xslt action, the Forms WG concluded that an XPath
> extension function called xslt() would be more appropriated (see 
> http://www.w3.org/2010/03/25-forms-minutes.html here ).
>
> So, Leigh Klotz suggested the following syntax example:
> <submission method="post" ref="ex:xslt(.....)" resource="save.cgi" />
> where @ref should be considered by xslt() as xml doc to be transformed.
>
> Such usage is very nice and appropriate, as allows user to make some 
client
> XSL transformations before sending data to server.
>
> I but I think that I would be more than useful if such XSL 
transformations
> can be made also during filling the form by user.
>
> In this regard, I would like to ask the community for ideas regarding 
the
> syntax and usage of xslt().
>
> Thank you,
> Claudius Teodorescu
>
>
>
> 
>
> -----
> Claudius Teodorescu
> http://kuberam.ro
>