New XPath extension function called xslt()

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

New XPath extension function called xslt()

claud108
Hi all,

I have made some extension for XSLTForms (see 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 here).

After analyzing this xslt action, the Forms WG concluded that an XPath extension function called xslt() would be more appropriated (see 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



 
Reply | Threaded
Open this post in threaded view
|

RE: New XPath extension function called xslt()

Nick Van den Bleeken-2
Hi Claudius,

There are already a couple of implementations that have this feature, because they are based on Saxon. Saxon has an extension function saxon:transform()[1].

>From Saxons' documentation: "This function takes as input a compiled XSLT stylesheet, and uses it to transform a source document into a result document. The first argument will generally be the result of calling the saxon:compile-stylesheet()  extension function. The second argument can be any node (usually a document node or element node), either read from external filestore using the doc() or document() function, or constructed programmatically..." (see [1] for the full description)

Saxon has a separate extension function saxon:compile-stylesheet()[2] (the result can be stored in a variable) because the 'compilation' process of stylesheet is quite heavy.

In your proposal this isn't strictly needed because you have a URI for a stylesheet and therefore you can calculate a last modified date. In Saxon's case it is node that contains the stylesheet. This approach has the advantage that you could create the stylesheet dynamically (based on data) but has the drawback that it is hard to know if you already have a compiled version of the stylesheet. (If you have the stylesheet available at a URI, you can use the doc() or document() function to parse the stylesheet document).

If we are going to standardize the function, I'm personally a bit leaning to the version that has the stylesheet as a node because it is more flexible. For the option having two functions (one that compiles the stylsheet and one that does the transform) opposed to just one, I'm a bit puzzled because I would prefer the two functions but we don't have variables in XForms yet, so there wouldn't be a lot gained with having two functions yet. Nevertheless I'm using variables a lot (they make forms authoring easier and require less evaluations of complex expressions at runtime), so I think we could go here with the two separate functions (compile and transform) because we will add support for variables hopefully sooner then later.

What is your opinion about this? (Definitely about having a node as input of the stylesheet opposed to the URI)

Regards,

Nick Van den Bleeken
R&D Manager

Phone: +32 3 821 01 70
Office Fax: +32 3 821 01 71
[hidden email]
http://www.inventivedesigners.com
Linked in

1: http://www.saxonica.com/documentation/extensions/functions/transform.html
2: http://www.saxonica.com/documentation/extensions/functions/compile-stylesheet.html

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf
> Of claud108
> Sent: donderdag 15 april 2010 13:25
> To: [hidden email]
> Subject: New XPath extension function called xslt()
>
>
> Hi all,
>
> I have made some extension for XSLTForms (see
> 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_xs
> lt_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
> --
> View this message in context: http://old.nabble.com/New-XPath-extension-
> function-called-xslt%28%29-tp28254037p28254037.html
> Sent from the w3.org - www-forms mailing list archive at Nabble.com.
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, 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 by MailScanner, and is
believed to be clean.
--



Reply | Threaded
Open this post in threaded view
|

Re: New XPath extension function called xslt()

claud108
Hi Nick,

If one uses for stylesheet the expression "instance('i0')/path/to/stylesheet" or "file://path/to/stylesheet" (or similar), I guess this solves the problem. It is a small difference if the stylesheet is contained in an instance or in a file.


Claudius Teodorescu


     

Reply | Threaded
Open this post in threaded view
|

RE: New XPath extension function called xslt()

Nick Van den Bleeken-2
Hi Claudius,

It is indeed a 'small' difference but supporting a stylsheet in the instance (or somewhere external with a uri using the doc() function) is much more flexible then only supporting a URI, but has the disadvantage that it is harder to detect if you already have a compiled version of the stylesheet and therefore it is maybe needed to have a separate compile and transform function, which is a bit more complex for the form author then only one function.

Regards,

Nick Van den Bleeken
R&D Manager

Phone: +32 3 821 01 70
Office Fax: +32 3 821 01 71
[hidden email]
http://www.inventivedesigners.com
Linked in


> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf
> Of Claudius Teodorescu
> Sent: donderdag 15 april 2010 14:36
> To: Nick Van den Bleeken
> Cc: [hidden email]
> Subject: Re: New XPath extension function called xslt()
>
> Hi Nick,
>
> If one uses for stylesheet the expression
> "instance('i0')/path/to/stylesheet" or "file://path/to/stylesheet" (or
> similar), I guess this solves the problem. It is a small difference if the
> stylesheet is contained in an instance or in a file.
>
>
> Claudius Teodorescu
>
>
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, 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 by MailScanner, and is
believed to be clean.
--



Reply | Threaded
Open this post in threaded view
|

RE: New XPath extension function called xslt()

Philip Fennell-3
Nick, Claudius,

Having used client-side XSLT via JavaScript with XForms and the Mozilla plug-in I found the following scenario to be very compelling:

1) A document instance
2) An XSLT instance
3) A 'view' instance

Upon a change in the document instance (Mutation Event) the XSLT stylesheet processes the 'document' instance to generate and replace the 'view' instance.

Now, that would be all well and good if we were able to render the 'view' instance. In order to make that work I had to take the result of the transform and convert it to a string and put that as the value of a text node in the 'view' instance. If that text node is bound to an xf:output with mediatype = 'text/html' then the plug-in interprets and parses the text as HTML and renders it accordingly. Nice.

But what is really cool is that if the transform also generates XForms mark-up too then that makes for some very dynamic and visually appealing forms. I believe that I'm not the only one to have tried this, or something similar, before.

So, that said, I agree with the idea of XSLT as an instance rather than a URI, but I don't think that the use case for transformation at submission is a compelling as the one for generating data views or applying complex updates to an instance during the editing process.

What would be useful, in conjunction with, this is the ability to bind an xf:output to complex content, the 'view' instance and setting a mediatype of 'application/svg+xml', 'application/xhtml+xml' or similar for that xf:output.


Regards

Philip Fennell
Consultant

Mark Logic Corporation
www.marklogic.com

E-mail: [hidden email]
Mobile: +44 (0)7824 830 866



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Nick Van den Bleeken
Sent: Thursday, April 15, 2010 1:44 PM
To: Claudius Teodorescu
Cc: [hidden email]
Subject: RE: New XPath extension function called xslt()

Hi Claudius,

It is indeed a 'small' difference but supporting a stylsheet in the instance (or somewhere external with a uri using the doc() function) is much more flexible then only supporting a URI, but has the disadvantage that it is harder to detect if you already have a compiled version of the stylesheet and therefore it is maybe needed to have a separate compile and transform function, which is a bit more complex for the form author then only one function.

Regards,

Nick Van den Bleeken
R&D Manager

Phone: +32 3 821 01 70
Office Fax: +32 3 821 01 71
[hidden email]
http://www.inventivedesigners.com
Linked in


> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf
> Of Claudius Teodorescu
> Sent: donderdag 15 april 2010 14:36
> To: Nick Van den Bleeken
> Cc: [hidden email]
> Subject: Re: New XPath extension function called xslt()
>
> Hi Nick,
>
> If one uses for stylesheet the expression
> "instance('i0')/path/to/stylesheet" or "file://path/to/stylesheet" (or
> similar), I guess this solves the problem. It is a small difference if the
> stylesheet is contained in an instance or in a file.
>
>
> Claudius Teodorescu
>
>
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, 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 by MailScanner, and is
believed to be clean.
--




Reply | Threaded
Open this post in threaded view
|

Re: New XPath extension function called xslt()

claud108
Philip,

If I understood well what you meant about "view" instance, this could be a usage of xslt(), namely rendering XHTML  (+ XForms).

AFAIK, Alain Couthures (XSLTForms) have some results regarding such rendering by using xf:output.

But I started thinking of an xslt function when I was faced with some complex client-side processing of invoice data, before sending data to server.

So, until now two use cases for xslt().

 Claudius Teodorescu
http://kuberam.ro



----- Original Message ----
From: Philip Fennell <[hidden email]>
To: Nick Van den Bleeken <[hidden email]>; Claudius Teodorescu <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Sent: Fri, April 16, 2010 12:10:28 AM
Subject: RE: New XPath extension function called xslt()

Nick, Claudius,

Having used client-side XSLT via JavaScript with XForms and the Mozilla plug-in I found the following scenario to be very compelling:

1) A document instance
2) An XSLT instance
3) A 'view' instance

Upon a change in the document instance (Mutation Event) the XSLT stylesheet processes the 'document' instance to generate and replace the 'view' instance.

Now, that would be all well and good if we were able to render the 'view' instance. In order to make that work I had to take the result of the transform and convert it to a string and put that as the value of a text node in the 'view' instance. If that text node is bound to an xf:output with mediatype = 'text/html' then the plug-in interprets and parses the text as HTML and renders it accordingly. Nice.

But what is really cool is that if the transform also generates XForms mark-up too then that makes for some very dynamic and visually appealing forms. I believe that I'm not the only one to have tried this, or something similar, before.

So, that said, I agree with the idea of XSLT as an instance rather than a URI, but I don't think that the use case for transformation at submission is a compelling as the one for generating data views or applying complex updates to an instance during the editing process.

What would be useful, in conjunction with, this is the ability to bind an xf:output to complex content, the 'view' instance and setting a mediatype of 'application/svg+xml', 'application/xhtml+xml' or similar for that xf:output.


Regards

Philip Fennell
Consultant

Mark Logic Corporation
www.marklogic.com

E-mail: [hidden email]
Mobile: +44 (0)7824 830 866



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Nick Van den Bleeken
Sent: Thursday, April 15, 2010 1:44 PM
To: Claudius Teodorescu
Cc: [hidden email]
Subject: RE: New XPath extension function called xslt()

Hi Claudius,

It is indeed a 'small' difference but supporting a stylsheet in the instance (or somewhere external with a uri using the doc() function) is much more flexible then only supporting a URI, but has the disadvantage that it is harder to detect if you already have a compiled version of the stylesheet and therefore it is maybe needed to have a separate compile and transform function, which is a bit more complex for the form author then only one function.

Regards,

Nick Van den Bleeken
R&D Manager

Phone: +32 3 821 01 70
Office Fax: +32 3 821 01 71
[hidden email]
http://www.inventivedesigners.com
Linked in


> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf
> Of Claudius Teodorescu
> Sent: donderdag 15 april 2010 14:36
> To: Nick Van den Bleeken
> Cc: [hidden email]
> Subject: Re: New XPath extension function called xslt()
>
> Hi Nick,
>
> If one uses for stylesheet the expression
> "instance('i0')/path/to/stylesheet" or "file://path/to/stylesheet" (or
> similar), I guess this solves the problem. It is a small difference if the
> stylesheet is contained in an instance or in a file.
>
>
> Claudius Teodorescu
>
>
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, 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 by MailScanner, and is
believed to be clean.
--


     

Reply | Threaded
Open this post in threaded view
|

Re: New XPath extension function called xslt()

claud108
In reply to this post by claud108
I have made a synthesis of the ideas regarding xslt(), which can be consulted here
Reply | Threaded
Open this post in threaded view
|

Re: New XPath extension function called xslt()

Alain COUTHURES
In reply to this post by claud108
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

> Hi all,
>
> I have made some extension for XSLTForms (see
> 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
>  


Reply | Threaded
Open this post in threaded view
|

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

John Boyer

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: [hidden email]  

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 <[hidden email]>
To: claud108 <[hidden email]>
Cc: [hidden email]
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

> Hi all,
>
> I have made some extension for XSLTForms (see
>
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
>  




Reply | Threaded
Open this post in threaded view
|

Re: New XPath extension function called xslt()

Erik Bruchez
In reply to this post by Alain COUTHURES
BTW as part of the "Node Creation XPath Functions" tentative feature
for XForms 1.2, we propose a parse() function. [1] A serialize()
function would be good too.

FWIW, see also the list of extension functions in Orbeon Forms [2],
which includes a serialize() function (which in fact is the Saxon
serialize() function).

-Erik

[1] http://www.w3.org/MarkUp/Forms/wiki/Node_'create'_functions
[2] http://wiki.orbeon.com/forms/doc/developer-guide/xforms-xpath-functions#TOC-XML-manipulation

On Fri, Apr 23, 2010 at 10:05 AM, COUTHURES Alain
<[hidden email]> wrote:

> 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
>
>> Hi all,
>>
>> I have made some extension for XSLTForms (see
>> 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
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

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

Alain COUTHURES
In reply to this post by John Boyer
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: [hidden email]  

Blog:
http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed:
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw


Reply | Threaded
Open this post in threaded view
|

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

John Boyer

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: [hidden email]  

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 <[hidden email]>
To: John Boyer/CanWest/IBM@IBMCA
Cc: claud108 <[hidden email]>, "[hidden email]" <[hidden email]>, [hidden email]
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@...  

Blog:
http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed:
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw



Reply | Threaded
Open this post in threaded view
|

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

Alain COUTHURES
John,

Well, at least for XSLTForms, there is an appreciable difference in speed because, with an action, the text result has to be parsed and stored in specific DOM-like objects then serialized in Javascript. It's also much easier for developers not to have to write actions on events.

Wouldn't it be more interesting to consider dependencies with ancestors: if a node has changed, all its ancestors have too??

Thanks!

-Alain

John Boyer a écrit :

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: [hidden email]  

Blog:
http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed:
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw
Reply | Threaded
Open this post in threaded view
|

Dependencies for XPath evaluation

Alain COUTHURES
John,

An xslt() function wouldn't be the only situation to be concerned with ancestor dependencies.

Here is a very basic test case:

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:ev="http://www.w3.org/2001/xml-events" xmlns:xf="http://www.w3.org/2002/xforms">
   <head>
        <title>Hello to the Bear Family</title>
        <xf:model id="mod">
         <xf:instance>
            <data xmlns="">
             <PersonGivenName>Teddy</PersonGivenName>
             <PersonName>Bear</PersonName>
            </data>
         </xf:instance>
        </xf:model>
   </head>
   <body>
        <xf:input ref="PersonGivenName" incremental="true">
            <xf:label>Please enter your first name: </xf:label>
        </xf:input>
        <br />
        <xf:output value=".">
            <xf:label>Hello </xf:label>
        </xf:output>
    </body>
</html>

As you can see, "Hello Teddy Bear" is expected and this should change to "Hello Ma Bear" when typing "Ma" instead of "Teddy".

I tested it against Mozilla Extension, Formula EMC and XSLTForms. Formula EMC is the only one succeeding but I don't know if Simon has implemented a dependency engine ;-)

What do you think?

Thanks!

-Alain

COUTHURES Alain a écrit :
John,

Well, at least for XSLTForms, there is an appreciable difference in speed because, with an action, the text result has to be parsed and stored in specific DOM-like objects then serialized in Javascript. It's also much easier for developers not to have to write actions on events.

Wouldn't it be more interesting to consider dependencies with ancestors: if a node has changed, all its ancestors have too??

Thanks!

-Alain

John Boyer a écrit :

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: [hidden email]  

Blog:
http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed:
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw

Reply | Threaded
Open this post in threaded view
|

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

Philip Fennell-3
In reply to this post by John Boyer
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: [hidden email] [[hidden email]] On Behalf Of John Boyer [[hidden email]]
Sent: 23 April 2010 18:38
To: COUTHURES Alain
Cc: claud108; [hidden email]; [hidden email]
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: [hidden email]  

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 <[hidden email]>
To: claud108 <[hidden email]>
Cc: [hidden email]
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

> Hi all,
>
> I have made some extension for XSLTForms (see
>
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
>  




Reply | Threaded
Open this post in threaded view
|

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

Nick Van den Bleeken-2
In reply to this post by John Boyer

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

[hidden email]

http://www.inventivedesigners.com

Linked in

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of John Boyer
Sent: vrijdag 23 april 2010 22:45
To: COUTHURES Alain
Cc: claud108; [hidden email]; [hidden email]
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: [hidden email]  

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 <[hidden email]>

To:

John Boyer/CanWest/IBM@IBMCA

Cc:

claud108 <[hidden email]>, "[hidden email]" <[hidden email]>, [hidden email]

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: [hidden email]  

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

Reply | Threaded
Open this post in threaded view
|

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

Nick Van den Bleeken-2
In reply to this post by Philip Fennell-3

Hi Philip,

 

Having xslt as a function (or transform which is a better name I think) instead of an action that you can also use it in an action, so I you prefer it in an action you can. But having it as an action doesn’t allows you to use it in a function.

 

Personally I think:

<xf:output value=”transform(…,…)” mediatype=” application/xhtml+xml”/>

 

Is easier discoverable, and more author friendly then:

 

<xf:instance id=”transform-result”>

   <result/>

</xf:input>

 

<xf:action ev:event="my-custom-event">

  <xf:transform .../>

</xf:actiom>

 

<xf:output ref=”instance(‘transform-result’) />

 

<xf:listen-to-data-change …>

  <dispatch name=" my-custom-event" target="model"/>

</ xf:listen-to-data-change>

 

With xf:listen-to-data-change a new construct to listen for data changes.

 

I will even argue that the function version is more ‘declarative’ bcz. It cleanly defines what you want to accomplish, in this case transform the data so it can be displayed (or transform the data before submitting it, in the submission example).

 

Could you please give your opinion about these statements? (I know we have to sort out some subtleties but I think not allowing the function in any of the attributes of a bind and in a ref or nodeset in the UI until more experience in practice will solve most issues…)

 

Regards,

 

 

Nick Van den Bleeken

R&D Manager

 

Phone: +32 3 821 01 70

Office Fax: +32 3 821 01 71

[hidden email]

http://www.inventivedesigners.com

Linked in

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Philip Fennell
Sent: maandag 26 april 2010 10:31
To: [hidden email]; [hidden email]
Cc: claud108; COUTHURES Alain
Subject: 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: [hidden email] [[hidden email]] On Behalf Of John Boyer [[hidden email]]
Sent: 23 April 2010 18:38
To: COUTHURES Alain
Cc: claud108; [hidden email]; [hidden email]
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: [hidden email]  

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 <[hidden email]>

To:

claud108 <[hidden email]>

Cc:

[hidden email]

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

> Hi all,
>
> I have made some extension for XSLTForms (see
> 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
>  




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

Reply | Threaded
Open this post in threaded view
|

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

Philip Fennell-3
In reply to this post by Nick Van den Bleeken-2
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: [hidden email] [[hidden email]] On Behalf Of Nick Van den Bleeken [[hidden email]]
Sent: 26 April 2010 13:38
To: John Boyer; COUTHURES Alain
Cc: claud108; [hidden email]; [hidden email]
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

[hidden email][hidden email][hidden email]

http://www.inventivedesigners.com

Linked in

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of John Boyer
Sent: vrijdag 23 april 2010 22:45
To: COUTHURES Alain
Cc: claud108; [hidden email]; [hidden email]
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: [hidden email]  

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 <[hidden email]>

To:

John Boyer/CanWest/IBM@IBMCA

Cc:

claud108 <[hidden email]>, "[hidden email]" <[hidden email]>, [hidden email]

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: [hidden email]  

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

Reply | Threaded
Open this post in threaded view
|

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

Nick Van den Bleeken-2

Philip and all,

 

As said in my other e-mail (sorry for posting two separate e-mails), you can still use it in an action. The advantage of having it as a function gives you the freedom of using it in any action you want (in practice the insert action would be the heaviest target I think), but you can also use it in the ref of a submission. Please see http://www.w3.org/MarkUp/Forms/wiki/Transform#Adapt_data_that_is_submitted for the example (I created this page to keep track of what the pro’s and con’s are of the two ‘proposals’, I only added the two examples but I’ll add a list of pro’s and con’s soon, please feel free to add examples and/or pro’s and con’s. I created this page to have a summary of the differences between the two approaches).

 

Regards,

 

Nick Van den Bleeken

R&D Manager

 

Phone: +32 3 821 01 70

Office Fax: +32 3 821 01 71

[hidden email]

http://www.inventivedesigners.com

Linked in

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Philip Fennell
Sent: maandag 26 april 2010 15:15
To: [hidden email]; [hidden email]
Cc: claud108; COUTHURES Alain
Subject: RE: New XPath extension function called xslt(), versus XSLT as an action

 

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: [hidden email] [[hidden email]] On Behalf Of Nick Van den Bleeken [[hidden email]]
Sent: 26 April 2010 13:38
To: John Boyer; COUTHURES Alain
Cc: claud108; [hidden email]; [hidden email]
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

[hidden email][hidden email]

http://www.inventivedesigners.com

Linked in

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of John Boyer
Sent: vrijdag 23 april 2010 22:45
To: COUTHURES Alain
Cc: claud108; [hidden email]; [hidden email]
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: [hidden email]  

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 <[hidden email]>

To:

John Boyer/CanWest/IBM@IBMCA

Cc:

claud108 <[hidden email]>, "[hidden email]" <[hidden email]>, [hidden email]

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: [hidden email]  

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


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