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

Hi Alain,

Agreed the ability to call the transform as a function is syntactically 
easier.  Not sure why there is any appreciable difference in speed.

Regarding dependencies, though, yes I think you are missing where the 
dependencies are coming from.
The output of the xslt might be a string, but the input to be transformed 
would be the *root* of some data node.  The function implicitly consumes 
all nodes in the subtree, but the parameter refers only to the root node, 
so the XPath containing xslt() would not have any dependencies on all the 
nodes.

If you call the xslt() function someplace that is ephemeral, like a 
submission ref, then it's OK because the result is obtained at a point in 
time, used and then discarded.  There is no long term tracking of 
dependencies on the XPath.  But an XPath in a UI binding, for example, is 
different.  The XForms processor is expected to make the UI reflect the 
state of the model.  So any change within the entire data subtree should 
reasonably cause your <xf:output value="xslt(data/root)"/> to be updated 
by running the transform again.  And when that doesn't happen, it looks 
like a language defect.

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:
John Boyer/CanWest/IBM@IBMCA
Cc:
claud108 <claud108@yahoo.com>, "www-forms@w3.org" <www-forms@w3.org>, 
public-forms@w3.org
Date:
04/23/2010 11:58 AM
Subject:
Re: New XPath extension function called xslt(), versus XSLT as an  action



John,

Calling a function in @value is easier but also much faster, especially 
for a Javascript implementation, when there is no need to store the result 
into an instance for just serializing it immediately after.

I don't see a dependency problem with an XPath function returning a text 
string: dependencies are inherited from parameters, at least it's 
implemented this way in XSLTForms (of course, ramdom() and now() functions 
are special ones...). Am I wrong?

And that's why I also considered a parse action ;-)

Thanks!

-Alain

 Boyer a écrit : 

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