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
>