RE: New XPath extension function called xslt(), versus XSLT as an action from alain.couthures@agencexml.com on 2010-04-26 (public-forms@w3.org from April 2010)

From: <alain.couthures@agencexml.com>
Date: Mon, 26 Apr 2010 15:45:27 +0200
To: <www-forms@w3.org>
To: <public-forms@w3.org>
To: <Philip.Fennell@marklogic.com>
Message-Id: <13862497.290601272289527575.JavaMail.servlet@kundenserver>
Philip and all,

The refresh problem is interesting and my suggestion could be to add another attribute, @refreshon for example, to indicate that refreshing should only occur when a custom event is received.

I consider @incremental to be a problem for speed and using different models is the only possibility I know to delimit the refresh operation. Maybe something like sets of controls, a control being allowed to be in different sets by just setting an attribute for that, could help to limit.

Cheers,

Alain Couthures

 @font-face {font-family: Cambria Math;}@font-face {font-family: Calibri;}@font-face {font-family: Tahoma;}@page Section1 {margin: 70.85pt 70.85pt 70.85pt 70.85pt; }P.MsoNormal {FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman","serif"}LI.MsoNormal {FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman","serif"}DIV.MsoNormal {FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman","serif"}A:link {COLOR: blue; TEXT-DECORATION: underline}SPAN.MsoHyperlink {COLOR: blue; TEXT-DECORATION: underline}A:visited {COLOR: purple; TEXT-DECORATION: underline}SPAN.MsoHyperlinkFollowed {COLOR: purple; TEXT-DECORATION: underline}P {FONT-SIZE: 12pt; MARGIN-LEFT: 0cm; MARGIN-RIGHT: 0cm; FONT-FAMILY: "Times New Roman","serif"}SPAN.EmailStyle18 {COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"}.MsoChpDefault {}DIV.Section1 {}<!--P {MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px}-->

Nick and all,
 
One of my concerns with the xslt() function is that in the example:
 
<xf:output value="xslt(‘my-stylesheet.xsl’, data/root)"/>
 
you (should expect to) get, by default, the output updating for every change in data/root and its descendants. However, there is no finesse in that. How do you control when the update occurs? If someone was using incremental updates then POW, POW, POW! you'd be thrashing the transformer like nobody's business. At least with an action you'd have better control over the invocation, wouldn't you? You can, for a start, make use of the if and while attributes on the action.
 
It may seem that it is 'author friendly' because the syntax is more compact but I think you'd find that in the long run it would be less efficient and less flexible, for the developer, than an action based transform.
 
 
Regards
 

Philip Fennell
 
Consultant
 
Mark Logic Corporation
 

From: public-forms-request@w3.org [public-forms-request@w3.org] On Behalf Of Nick Van den Bleeken [Nick.Van.den.Bleeken@inventivegroup.com]
Sent: 26 April 2010 13:38
To: John Boyer; COUTHURES Alain
Cc: claud108; public-forms@w3.org; www-forms@w3.org
Subject: RE: New XPath extension function called xslt(), versus XSLT as an action





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.
 
Regards,  
 
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
http://www.inventivedesigners.com
Linked in
 



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

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




-- 
This message has been scanned for viruses and 
dangerous content, and is believed to be clean. 
-- 
Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer


-- 
This message has been scanned for viruses and 
dangerous content, and is believed to be clean. 
--
Received on Monday, 26 April 2010 13:46:06 UTC