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

As the notion of client-side XSLT and XForms is a subject dear to my heart I'll chip in here also and give my 'two penneth'.

> 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.



I agree with John's point here. Having the transform invoked via an action, which is what I've implemented previously and had always imagined it to work that way, seems a much safer, concrete and more reasonable bet than having a function that could be invoked in some surprising ways.



I think it is easier and more readable, from the constructional point of view, for the developer to explicitly define transform actions, triggered by events. The difference may be some what subtle but none the less important in my opinion.



In a similar style to an xf:insert, an xf:transform would clearly define both the source (origin), result (context | nodeset) and the transform instances. Defining the transform(s) as instances would also be far more declarative from a constructional view point. In this way there would not be a need for a doc() function. I guess one can go the extra mile and allow run-time evaluation of the location of the transform like the xf:case and xf:resource elements as well as xf:parameter elements like the header elements for xf:submission.



The only other point I'd wish to raise here is the issues of binding xf:output to complex types. Currently we can't, but if we introduce xf:transform (or xslt()) then one of the potential use cases will be to generate views (SVG or XHTML) and then I think it will become a must and I'm not sure that:



<xf:output value="serialize(xslt(..., ...), ...)", mediatype="text/html"/>



is a particularly nice solution. The above example is, in effect, what you currently have to do with JavaScript and the Mozilla plug-in in order to render the result of a client-side transform. Where as:



<xf:action ev:event="...">

  <xf:transform .../>

</xf:actiom>



...



<xf:output ref="..." mediatype="application/xhtml+xml"/>



is obviously more verbose but I think it is clearer and easier to construct (IMHO).



I'm sure I've probably missed a few bits in one or other of those examples but I hope you get the gist of it.





Regards



Philip Fennell



Consultant



Mark Logic Corporation








________________________________
From: public-forms-request@w3.org [public-forms-request@w3.org] On Behalf Of John Boyer [boyerj@ca.ibm.com]
Sent: 23 April 2010 18:38
To: COUTHURES Alain
Cc: claud108; www-forms@w3.org; public-forms@w3.org
Subject: 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<http://www.agencexml.com/>

> Hi all,
>
> I have made some extension for XSLTForms (see
> http://extxsltforms.sourceforge.net<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<http://kuberam.ro/>
>