W3C home > Mailing lists > Public > public-forms@w3.org > April 2010

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

From: Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>
Date: Mon, 26 Apr 2010 14:38:02 +0200
To: John Boyer <boyerj@ca.ibm.com>, COUTHURES Alain <alain.couthures@agencexml.com>
CC: claud108 <claud108@yahoo.com>, "public-forms@w3.org" <public-forms@w3.org>, "www-forms@w3.org" <www-forms@w3.org>
Message-ID: <98F519CDC2FA6146AE00069E9A1D91FD87074449D6@erganix.dc.intranet>
Hi John and others,

I'm not completely agreeing I do think <xf:output value="xslt('my-stylesheet.xsl', data/root)"/> should be updated when any node in the subtree changes. The same should happen when you use our id() function [1] when you provide the second nodeset attribute, when the output should update when new nodes are returned by the id() due to a change in a descendant of the nodeset. I know that currently this isn't the case, but I see this as 'bug'.

In my opinion xslt as a function can be better optimized then the action version, because you don't require the data to be stored in an instance. Two nice examples would be when used on a ref in a submission and the example of an xf:output you can store it directly as the markup that is displayed (and only recreate the markup when its input changes, this can be nicely optimized by an implementation). Furthermore is the function version much more author friendly.


Nick Van den Bleeken
R&D Manager

Phone: +32 3 821 01 70
Office Fax: +32 3 821 01 71
nick.van.den.bleeken@inventivegroup.com <mailto:nick.van.den.bleeken@inventivegroup.com>
Linked in<http://be.linkedin.com/in/nvdbleek>

From: public-forms-request@w3.org [mailto:public-forms-request@w3.org] On Behalf Of John Boyer
Sent: vrijdag 23 april 2010 22:45
Cc: claud108; public-forms@w3.org; www-forms@w3.org
Subject: 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.

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


COUTHURES Alain <alain.couthures@agencexml.com>


John Boyer/CanWest/IBM@IBMCA


claud108 <claud108@yahoo.com>, "www-forms@w3.org" <www-forms@w3.org>, public-forms@w3.org


04/23/2010 11:58 AM


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



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 ;-)



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.

John M. Boyer, Ph.D.
STSM, Lotus Forms
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com<mailto: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

This message has been scanned for viruses and
dangerous content, and is believed to be clean.

Inventive Designers' Email Disclaimer:

This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Monday, 26 April 2010 12:38:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:48:40 UTC