RE: New XPath extension function called xslt()

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

RE: New XPath extension function called xslt()

claud108
Hi, all,

First of all, thank you for paying attention to this proposal and for sharing your opinions about it. All these opinions are very instructive and reveal different facets of the discussed topic both from conceptual point of view and from practical usage in real-world web applications.

I would like to share my comments, too.

So, I maintain my initial opinion about an xslt action for the following reasons:

1. When using xslt as a function, the syntax is by far more simple. But, conceptually speaking, an XSL transformation has nothing to do with XPath functions. I consider that, within XForms scope, it is an action, just like the other XForms actions (setvalue, insert, delete, etc.).

2. Considering xslt as an action, one can avoid all the "problems" caused by "dependencies" (as were mentioned above).

3. Such xslt action can be easily be used, wrapped in an action element, to process data when "xforms-submit" event is triggered, just like other actions we are doing right now before submissions in our webapps. It can also be used, wrapped in an action element, to process data when "xforms-value-changed" event is triggered, in order to update an UI subform. It can receive @if, @while. Or it can be wrapped by an action element acting as handler called by a listener, according to XML Events.


Claudius Teodorescu
http://kuberam.ro


Reply | Threaded
Open this post in threaded view
|

RE: New XPath extension function called xslt()

claud108
Hi, all,

First of all, thank you for paying attention to this proposal and for sharing your opinions about it. All these opinions are very instructive and reveal different facets of the discussed topic both from conceptual point of view and from practical usage in real-world web applications.

I would like to share my opinions, too.

So, I maintain my initial opinion about an xslt action for the following reasons:

1. When using xslt as a function, the syntax is by far more simple. But, conceptually speaking, an XSL transformation has nothing to do with XPath functions. I consider that, within XForms scope, it is an action, just like the other XForms actions (setvalue, insert, delete, etc.).
2. Considering xslt as an action, one can avoid all the "problems" caused by its "dependencies" (as were mentioned above) and the usage of


Claudius Teodorescu
http://kuberam.ro


Reply | Threaded
Open this post in threaded view
|

Re: New XPath extension function called xslt()

Ulrich Nicolas Lissé-3
In reply to this post by claud108
Dear Group,

I'm too in favor of a transform action instead of a xslt() function for
the following reasons:

1. Such an action would have clearly defined semantics wrt model
updates. The dependency problem imposed by an function simply does not
exist for an action.

2. It is not true that a transform action would duplicate existing
insert functionality. First, a carefully designed transform action would
not be limited to XSLT, but could also employ other technologies capable
of transforming XML in wider sense (XProc, XQuery). Second, the insert
action is overly complex and generic. IIRC, there had been proposals to
build simpler actions for specific use cases like copy.

3. I doubt that it's easier for authors to use the function because they
usually don't care for side effects. It would be very hard for them to
track down dependency problems caused by such a function. Also, having
an action triggered by events fits much better into the declarative
application model of XForms.

4. Use cases like using a xslt() function in binding expressions or MIPs
would not be directly feasible with an action. However, this is not to
blame on the action. Seems like the XForms processing model could use
some more events ;)

5. The argument (heared at the last telecon) that an xslt() function
would fit better to XSLT's functional nature doesn't hold. Just because
the language used for a transformation is a functional one doesn't
necessarily mean that an invocation of such a transformation is
functional too. Obviously it isn't --it has side effects.

6. Last but not least implementers could be encouraged to provide xslt()
as an extension function. Maybe it would be a candidate for EXForms. But
I don't see a need to specifiy that as part of the XForms Spec.

Regards,
Uli.

On 05.05.10 11:37, Claudius Teodorescu wrote:

> Hi, all,
>
> First of all, thank you for paying attention to this proposal and for
> sharing your opinions about it. All these opinions are very instructive
> and reveal different facets of the discussed topic both from conceptual
> point of view and from practical usage in real-world web applications.
>
> I would like to share my comments, too.
>
> So, I maintain my initial opinion about an xslt action for the following
> reasons:
>
> 1. When using xslt as a function, the syntax is by far more simple. But,
> conceptually speaking, an XSL transformation has nothing to do with
> XPath functions. I consider that, within XForms scope, it is an action,
> just like the other XForms actions (setvalue, insert, delete, etc.).
>
> 2. Considering xslt as an action, one can avoid all the "problems"
> caused by "dependencies" (as were mentioned above).
>
> 3. Such xslt action can be easily be used, wrapped in an action element,
> to process data when "xforms-submit" event is triggered, just like other
> actions we are doing right now before submissions in our webapps. It can
> also be used, wrapped in an action element, to process data when
> "xforms-value-changed" event is triggered, in order to update an UI
> subform. It can receive @if, @while. Or it can be wrapped by an action
> element acting as handler called by a listener, according to XML Events.
>
>
> Claudius Teodorescu
> http://kuberam.ro
>
>


--
Ulrich Nicolas Lissé

Reply | Threaded
Open this post in threaded view
|

Re: New XPath extension function called xslt()

claud108
Hi,

1. I think that such action not-limited to XSLT (deserving the name of "transform" action in this case) is a marvelous generalization of an xslt action.
In such case, I think that a transform action could be part of the XForms Spec, as a good tool for processing XML server-side by using complex approaches (XSLT, etc.).

2. Your idea about using XProc and XQuery sounds very interesting. Could you be a bit more explicit about this?
 
Claudius Teodorescu
http://kuberam.ro

Reply | Threaded
Open this post in threaded view
|

RE: New XPath extension function called xslt()

Klotz, Leigh
In reply to this post by Ulrich Nicolas Lissé-3
Uli,
I believe we should do more of our work in the style of exforms, whether it is published by W3C or outside W3C.
I don’t see much of a difference technically.
Leigh.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Ulrich Nicolas Lissé
Sent: Wednesday, May 05, 2010 5:45 AM
To: Claudius Teodorescu
Cc: Forms WG
Subject: Re: New XPath extension function called xslt()

Dear Group,

I'm too in favor of a transform action instead of a xslt() function for the following reasons:

1. Such an action would have clearly defined semantics wrt model updates. The dependency problem imposed by an function simply does not exist for an action.

2. It is not true that a transform action would duplicate existing insert functionality. First, a carefully designed transform action would not be limited to XSLT, but could also employ other technologies capable of transforming XML in wider sense (XProc, XQuery). Second, the insert action is overly complex and generic. IIRC, there had been proposals to build simpler actions for specific use cases like copy.

3. I doubt that it's easier for authors to use the function because they usually don't care for side effects. It would be very hard for them to track down dependency problems caused by such a function. Also, having an action triggered by events fits much better into the declarative application model of XForms.

4. Use cases like using a xslt() function in binding expressions or MIPs would not be directly feasible with an action. However, this is not to blame on the action. Seems like the XForms processing model could use some more events ;)

5. The argument (heared at the last telecon) that an xslt() function would fit better to XSLT's functional nature doesn't hold. Just because the language used for a transformation is a functional one doesn't necessarily mean that an invocation of such a transformation is functional too. Obviously it isn't --it has side effects.

6. Last but not least implementers could be encouraged to provide xslt() as an extension function. Maybe it would be a candidate for EXForms. But I don't see a need to specifiy that as part of the XForms Spec.

Regards,
Uli.

On 05.05.10 11:37, Claudius Teodorescu wrote:

> Hi, all,
>
> First of all, thank you for paying attention to this proposal and for
> sharing your opinions about it. All these opinions are very
> instructive and reveal different facets of the discussed topic both
> from conceptual point of view and from practical usage in real-world web applications.
>
> I would like to share my comments, too.
>
> So, I maintain my initial opinion about an xslt action for the
> following
> reasons:
>
> 1. When using xslt as a function, the syntax is by far more simple.
> But, conceptually speaking, an XSL transformation has nothing to do
> with XPath functions. I consider that, within XForms scope, it is an
> action, just like the other XForms actions (setvalue, insert, delete, etc.).
>
> 2. Considering xslt as an action, one can avoid all the "problems"
> caused by "dependencies" (as were mentioned above).
>
> 3. Such xslt action can be easily be used, wrapped in an action
> element, to process data when "xforms-submit" event is triggered, just
> like other actions we are doing right now before submissions in our
> webapps. It can also be used, wrapped in an action element, to process
> data when "xforms-value-changed" event is triggered, in order to
> update an UI subform. It can receive @if, @while. Or it can be wrapped
> by an action element acting as handler called by a listener, according to XML Events.
>
>
> Claudius Teodorescu
> http://kuberam.ro
>
>


--
Ulrich Nicolas Lissé

Reply | Threaded
Open this post in threaded view
|

Re: New XPath extension function called xslt()

claud108
In reply to this post by Ulrich Nicolas Lissé-3
Hi,

Thinking of the nice idea abour XQuery and XProc in broswer, through "transform" action:
XQuery - by using http://www.xqib.org/
XProc - by using xprocxq (developed by Jim Fuller) on top of xqib.
 
Claudius Teodorescu
http://kuberam.ro

Reply | Threaded
Open this post in threaded view
|

RE: New XPath extension function called xslt()

Toman_Vojtech

FYI, at EMC we are working on making our Calumet XProc processor (originally Java-based) available also as a 100% JavaScript component. We already have a version that works across the major web browsers and supports most of the required XProc features.

 

I have already demoed the JavaScript version of Calumet a couple of times. What might be interesting for the XForms folks is that we have also experimented with combining client-side XProc together with client-side XForms (using our Formula XForms implementation). Most of the examples we have revolve around using XForms for adding interactivity to XProc pipelines: for instance, an XForms extension XProc step can be used for displaying XForms (static or dynamically generated) to the end-user while executing the pipeline. This allows for defining XML-based interactive procedures that execute completely on the client-side, with no interaction with the server-side.

 

We haven't tried the opposite direction (using XProc in XForms) yet, but I don't see why this shouldn't be possible.

 

Regards,

Vojtech

 

--

Vojtech Toman

Principal Software Engineer

EMC Corporation

[hidden email]

http://developer.emc.com/xmltech

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Claudius Teodorescu
Sent: Friday, May 07, 2010 12:18 PM
To: Ulrich Nicolas Lissé
Cc: [hidden email]
Subject: Re: New XPath extension function called xslt()

 

Hi,

Thinking of the nice idea abour XQuery and XProc in broswer, through "transform" action:
XQuery - by using http://www.xqib.org/
XProc - by using xprocxq (developed by Jim Fuller) on top of xqib.

 

Claudius Teodorescu
http://kuberam.ro

 

Reply | Threaded
Open this post in threaded view
|

Re: New XPath extension function called xslt()

Manfred Staudinger
Hi Toman,

On 07/05/2010, [hidden email] <[hidden email]> wrote:
> What might be interesting for the XForms folks is that we have also
> experimented with combining client-side XProc together with client-side
> XForms (using our Formula XForms implementation). Most of the examples we
> have revolve around using XForms for adding interactivity to XProc
> pipelines: for instance, an XForms extension XProc step can be used for
> displaying XForms (static or dynamically generated) to the end-user while
> executing the pipeline.
This sounds very interesting indeed and I would like to study those
examples in detail: can you recommend an URL where to start off?

Regards,
Manfred

Reply | Threaded
Open this post in threaded view
|

RE: New XPath extension function called xslt()

Toman_Vojtech
Manfred,

At the moment I can't point you to any publicly available resources. I
have presented the client-side XProc/XForms demo at the DemoJam at XML
Prague earlier this year, but apart from that, we haven't published any
materials about this yet.

The plan is to distribute our XProc implementation as a dual
Java/JavaScript package, but there is still work that needs to be done
to make the JavaScript version ready for a public release. When this
happens, we will most definitely publish some demos and articles on our
EMC Developer Network site (http://developer.emc.com/xmltech).

Regards,
Vojtech

> -----Original Message-----
> From: Manfred Staudinger [mailto:[hidden email]]
> Sent: Friday, May 07, 2010 2:34 PM
> To: [hidden email]
> Cc: Toman, Vojtech
> Subject: Re: New XPath extension function called xslt()
>
> Hi Toman,
>
> On 07/05/2010, [hidden email] <[hidden email]> wrote:
> > What might be interesting for the XForms folks is that we have also
> > experimented with combining client-side XProc together with
client-side
> > XForms (using our Formula XForms implementation). Most of the
examples we
> > have revolve around using XForms for adding interactivity to XProc
> > pipelines: for instance, an XForms extension XProc step can be used
for
> > displaying XForms (static or dynamically generated) to the end-user
while
> > executing the pipeline.
> This sounds very interesting indeed and I would like to study those
> examples in detail: can you recommend an URL where to start off?
>
> Regards,
> Manfred


Reply | Threaded
Open this post in threaded view
|

Re: New XPath extension function called xslt()

Erik Bruchez
In reply to this post by claud108
> conceptually speaking, an XSL transformation has nothing to do with XPath
> functions

FWIW, I don't think that's a fair statement. XPath 2.0, XQuery 1.0,
and XSLT 2.0 are very close languages. An XSLT transformation is
conceptually a function, taking one or more inputs and returning one
or more inputs.

(Mike Kay wrote an article called "Comparing XSLT and XQuery" which
now seems to have disappeared from the interwebs.)

-Erik