XSLT extension action - continued

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

XSLT extension action - continued

claud108
Hi,

I would like to continue the implementation in eXSLTForms of the XForms extension action I already integrated into it, called for now "xslt".

About this, there were some discussions about what this should be: function or action.

I decided to continue with it as an action and, as English is not my native language and this is the most adequate ML, I would like to ask community for suggestions about the future name of it.

I would like to call it "process" action as now I can make XSLT transformation with it in XSLTForms and I want also, through eDIB project (http://sourceforge.net/projects/edib/) (eXist XML Database In Browser - one can make XQuery queries from page to an eXist XMLDB installed on client), to process data using XQuery and, I hope, XProc. But I am open to suggestions for other names.

A possible syntax fallows:
<xf:process type="xslt" processor="exist-client" source="instance('i2')/pac" transformer="doc('test.xsl')" target="instance('i0')/v1" parameters="instance('i2')/parameters"/>

Thanks in advance,
Claudius

Reply | Threaded
Open this post in threaded view
|

Re: XSLT extension action - continued

claud108
Hi,

I thought about the following syntax:

<xf:process
        type="xslt | xquery | xproc"
        processor="exist-client"
        input="instance('i2')/pac"
        transformer="doc('test.xsl')"
        output="instance('i0')/v1"
        parameters="instance('i2')/parameters"/>
* instead of @transformer should be @processAgent, @processing-agent, or @agent.



Reply | Threaded
Open this post in threaded view
|

RE: XSLT extension action - continued

Nick Van den Bleeken-2
Hi,


* What do you think of the name 'transform' for the action?
* Isn't 'ref' a better name for the 'output' attribute (to be conform with the rest of XForms)?
* (not sure if this one) What do you think of 'origin' instead of input (to be consistent with insert action).
* Personally I like the parameters attribute (we could also use this approach if we decide to also add a transform() function), but wouldn't it be more form author friendly to support (also) param child elements which have 'name', 'ref'  and 'value' attributes?

Some questions:
* Are you supporting the 'context' attribute on this action?
*What is the use of the processor attribute?

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 claud108
> Sent: woensdag 25 augustus 2010 21:21
> To: [hidden email]
> Subject: Re: XSLT extension action - continued
>
>
> Hi,
>
> I thought about the following syntax:
>
> <xf:process
>       type="xslt | xquery | xproc"
>       processor="exist-client"
>       input="instance('i2')/pac"
>       transformer="doc('test.xsl')"
>       output="instance('i0')/v1"
>       parameters="instance('i2')/parameters"/>
> * instead of @transformer should be @processAgent, @processing-agent, or
> @agent.
>
>
>
>
>
> -----
> Claudius Teodorescu
> http://kuberam.ro
> --
> View this message in context: http://old.nabble.com/XSLT-extension-action-
> --continued-tp29495671p29535713.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: XSLT extension action - continued

claud108
Hi,


* What do you think of the name 'transform' for the action?

When Uli proposed this name, I very agreed with it, as it seemed to me as appropriate for XSLT transformations. But this was until I found out that other data processing can be made in browser, namely:
a. Brett Zamir made XDIB, an integration of Sedna XMLDB in a Firefox plugin, allowing users to do XQuery processing;
b. the project eDIB, which I started, allowing XQuery and XProc processing.
This is why I thought of 'process' name for the action, as being more general and comprehensive.


* Isn't 'ref' a better name for the 'output' attribute (to be conform with the rest of XForms)?
* (not sure if this one) What do you think of 'origin' instead of input (to be consistent with insert action).

In the context of a 'process' action, allowing XSLT, XQuery, or XProc data processing, I think that 'input' and 'output' are more adequate, being on their turn more general, For instance, they could support a reference to a URL in an eXist instance located on the client machine (as is the case with eDIB project), and this doesn't seem to me as being in the spirit or 'ref' and 'origin' attributes. Once again, English isn't my native language, so that is possible for me to miss some of its subtleties; this is the reason why I asked on this ML.


* Personally I like the parameters attribute (we could also use this approach if we decide to also add a transform() function), but wouldn't it be more form author friendly to support (also) param child elements which have 'name', 'ref'  and 'value' attributes?

This is a very nice idea, thank you.


Some questions:
* Are you supporting the 'context' attribute on this action?

No.

*What is the use of the processor attribute?

'Processor' attribute allows implementation to differentiate the various processors that can be used to the XSLT, XQuery, or XProc processing.
I mentioned above of two different processors (XDIB and eDIB) but, on the other hand, Alain Couthures said on Tweeter that he is thinking of XQuery in the browser, implemented in Javascript, and I am also thinking that someone could make some nice plugins with Saxon and/or Calabash (for instance), in order to allow users to do these types of data processing in browser.


Regards,
Claudius

Reply | Threaded
Open this post in threaded view
|

RE: XSLT extension action - continued

Philip Fennell-3

Hello all,

 
 
> This is why I thought of 'process' name for the action, as being more general and comprehensive.
 
Originally I saw the option to invoke XSLT within an XForm as an opportunity to apply an XSLT transformation to some part or all of an instance data. Given the possibility of having XQuery and XProc available as well does not, to my mind, change the nature of the action that you are performing, which in this case is a transformation. Therefore, I'd argue that an xf:transform action is more suitable than xf:process especially as the XForms engine does many other 'processing' steps as part an of its work.
 
 
> In the context of a 'process' action, allowing XSLT, XQuery, or XProc data processing,
> I think that 'input' and 'output' are more adequate, being on their turn more general.
 
Given that XSLT has the notion of source and result documents, XQuery works off of collections and generates sequences of nodes, XProc is the only one that has the notion of inputs and outputs. I would like to see the suggested xf:transform action be aligned with XForms rather than a collection of possible, and varying, external processing tools. Therefore, I'd agree with Nick and would suggest the use of @ref, @origin and @context. After all, the action is being applied to an instance within the form. The transform being invoked may call upon external resources but I don't agree that the action should be able to, in effect, be applied to external resources, and by external I mean both embedded XML databases and resources external to the browser. If you need to reference an external resource then you should use an xf:submission to retrieve it and then apply the action to it upon the xforms-submit-done event.
 
 
> * Personally I like the parameters attribute (we could also use this approach if we
> decide to also add a transform() function), but wouldn't it be more form author friendly
> to support (also) param child elements which have 'name', 'ref'  and 'value' attributes?
Agreed.
 
 
> 'Processor' attribute allows implementation to differentiate the various processors
> that can be used to the XSLT, XQuery, or XProc processing.
I can foresee that there could be many possible processors available to an XForms implementation but, not being an XForms implementer, I'm not sure how you'd go about finding-out what ones where available within, say, a web browser or any other client. I'd have thought that an implementation would be more closely coupled to the environment it is deployed in and therefore those choices would be defined up-front. If this is the case then just having the type attribute should be sufficient. However, if this was not the case then you could only go by, in the case of XSLT, the system-property('xsl:product-name'), XProc has p:system-property('p:product-name') but I'm not sure XQuery has this feature.
 
 
Regards
 

Philip Fennell

Consultant
MarkLogic Corporation

Mobile +44 (0) 7824 830 866

email  [hidden email]
web    www.marklogic.com


This e-mail and any accompanying attachments are confidential. The information is intended solely for the use of the individual to whom it is addressed. Any review, disclosure, copying, distribution, or use of this e-mail communication by others is strictly prohibited. If you are not the intended recipient, please notify us immediately by returning this message to the sender and delete all copies. Thank you for your cooperation.

 
 

From: [hidden email] [[hidden email]] On Behalf Of Claudius Teodorescu [[hidden email]]
Sent: 01 September 2010 11:04
To: Nick Van den Bleeken
Cc: [hidden email]
Subject: Re: XSLT extension action - continued

Hi,


* What do you think of the name 'transform' for the action?

When Uli proposed this name, I very agreed with it, as it seemed to me as appropriate for XSLT transformations. But this was until I found out that other data processing can be made in browser, namely:
a. Brett Zamir made XDIB, an integration of Sedna XMLDB in a Firefox plugin, allowing users to do XQuery processing;
b. the project eDIB, which I started, allowing XQuery and XProc processing.
This is why I thought of 'process' name for the action, as being more general and comprehensive.


* Isn't 'ref' a better name for the 'output' attribute (to be conform with the rest of XForms)?
* (not sure if this one) What do you think of 'origin' instead of input (to be consistent with insert action).

In the context of a 'process' action, allowing XSLT, XQuery, or XProc data processing, I think that 'input' and 'output' are more adequate, being on their turn more general, For instance, they could support a reference to a URL in an eXist instance located on the client machine (as is the case with eDIB project), and this doesn't seem to me as being in the spirit or 'ref' and 'origin' attributes. Once again, English isn't my native language, so that is possible for me to miss some of its subtleties; this is the reason why I asked on this ML.


* Personally I like the parameters attribute (we could also use this approach if we decide to also add a transform() function), but wouldn't it be more form author friendly to support (also) param child elements which have 'name', 'ref'  and 'value' attributes?

This is a very nice idea, thank you.


Some questions:
* Are you supporting the 'context' attribute on this action?

No.

*What is the use of the processor attribute?

'Processor' attribute allows implementation to differentiate the various processors that can be used to the XSLT, XQuery, or XProc processing.
I mentioned above of two different processors (XDIB and eDIB) but, on the other hand, Alain Couthures said on Tweeter that he is thinking of XQuery in the browser, implemented in Javascript, and I am also thinking that someone could make some nice plugins with Saxon and/or Calabash (for instance), in order to allow users to do these types of data processing in browser.


Regards,
Claudius

Reply | Threaded
Open this post in threaded view
|

RE: XSLT extension action - continued

Nick Van den Bleeken-2

Hi Claudius,

 

I wanted to reply on your reply, but then noticed that Philip already replied and elaborated on why he thinks why the action should be named ‘transform’ and use of @ref, @origin and @context. His reasoning is exactly why I proposed those ‘changes’, maybe I should have elaborated a bit more in my original reply… What do you think of this reasoning?

 

For the @processor I also agree with Philip  and think that this attribute shouldn’t be in the spec. because it would be hard to make it work cross implementation, it is unlikely that many different implementations are going to share the same processors. It can be an attribute on the action in a foreign namespace…

 

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: Philip Fennell [mailto:[hidden email]]
Sent: woensdag 1 september 2010 13:27
To: Claudius Teodorescu; Nick Van den Bleeken
Cc: [hidden email]
Subject: RE: XSLT extension action - continued

 

Hello all,

 

 

> This is why I thought of 'process' name for the action, as being more general and comprehensive.

 

Originally I saw the option to invoke XSLT within an XForm as an opportunity to apply an XSLT transformation to some part or all of an instance data. Given the possibility of having XQuery and XProc available as well does not, to my mind, change the nature of the action that you are performing, which in this case is a transformation. Therefore, I'd argue that an xf:transform action is more suitable than xf:process especially as the XForms engine does many other 'processing' steps as part an of its work.

 

 

> In the context of a 'process' action, allowing XSLT, XQuery, or XProc data processing,

> I think that 'input' and 'output' are more adequate, being on their turn more general.

 

Given that XSLT has the notion of source and result documents, XQuery works off of collections and generates sequences of nodes, XProc is the only one that has the notion of inputs and outputs. I would like to see the suggested xf:transform action be aligned with XForms rather than a collection of possible, and varying, external processing tools. Therefore, I'd agree with Nick and would suggest the use of @ref, @origin and @context. After all, the action is being applied to an instance within the form. The transform being invoked may call upon external resources but I don't agree that the action should be able to, in effect, be applied to external resources, and by external I mean both embedded XML databases and resources external to the browser. If you need to reference an external resource then you should use an xf:submission to retrieve it and then apply the action to it upon the xforms-submit-done event.

 

 

> * Personally I like the parameters attribute (we could also use this approach if we

> decide to also add a transform() function), but wouldn't it be more form author friendly

> to support (also) param child elements which have 'name', 'ref'  and 'value' attributes?

Agreed.

 

 

> 'Processor' attribute allows implementation to differentiate the various processors

> that can be used to the XSLT, XQuery, or XProc processing.

I can foresee that there could be many possible processors available to an XForms implementation but, not being an XForms implementer, I'm not sure how you'd go about finding-out what ones where available within, say, a web browser or any other client. I'd have thought that an implementation would be more closely coupled to the environment it is deployed in and therefore those choices would be defined up-front. If this is the case then just having the type attribute should be sufficient. However, if this was not the case then you could only go by, in the case of XSLT, the system-property('xsl:product-name'), XProc has p:system-property('p:product-name') but I'm not sure XQuery has this feature.

 

 

Regards

 

Philip Fennell

Consultant
MarkLogic Corporation

Mobile +44 (0) 7824 830 866

email  [hidden email]
web    www.marklogic.com

 

This e-mail and any accompanying attachments are confidential. The information is intended solely for the use of the individual to whom it is addressed. Any review, disclosure, copying, distribution, or use of this e-mail communication by others is strictly prohibited. If you are not the intended recipient, please notify us immediately by returning this message to the sender and delete all copies. Thank you for your cooperation.

 

 


From: [hidden email] [[hidden email]] On Behalf Of Claudius Teodorescu [[hidden email]]
Sent: 01 September 2010 11:04
To: Nick Van den Bleeken
Cc: [hidden email]
Subject: Re: XSLT extension action - continued

Hi,


* What do you think of the name 'transform' for the action?

When Uli proposed this name, I very agreed with it, as it seemed to me as appropriate for XSLT transformations. But this was until I found out that other data processing can be made in browser, namely:
a. Brett Zamir made XDIB, an integration of Sedna XMLDB in a Firefox plugin, allowing users to do XQuery processing;
b. the project eDIB, which I started, allowing XQuery and XProc processing.
This is why I thought of 'process' name for the action, as being more general and comprehensive.


* Isn't 'ref' a better name for the 'output' attribute (to be conform with the rest of XForms)?
* (not sure if this one) What do you think of 'origin' instead of input (to be consistent with insert action).

In the context of a 'process' action, allowing XSLT, XQuery, or XProc data processing, I think that 'input' and 'output' are more adequate, being on their turn more general, For instance, they could support a reference to a URL in an eXist instance located on the client machine (as is the case with eDIB project), and this doesn't seem to me as being in the spirit or 'ref' and 'origin' attributes. Once again, English isn't my native language, so that is possible for me to miss some of its subtleties; this is the reason why I asked on this ML.


* Personally I like the parameters attribute (we could also use this approach if we decide to also add a transform() function), but wouldn't it be more form author friendly to support (also) param child elements which have 'name', 'ref'  and 'value' attributes?

This is a very nice idea, thank you.


Some questions:
* Are you supporting the 'context' attribute on this action?

No.

*What is the use of the processor attribute?

'Processor' attribute allows implementation to differentiate the various processors that can be used to the XSLT, XQuery, or XProc processing.
I mentioned above of two different processors (XDIB and eDIB) but, on the other hand, Alain Couthures said on Tweeter that he is thinking of XQuery in the browser, implemented in Javascript, and I am also thinking that someone could make some nice plugins with Saxon and/or Calabash (for instance), in order to allow users to do these types of data processing in browser.


Regards,
Claudius

 


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

Fw: XSLT extension action - continued

claud108

Hi,


"Transform" is a very nice name in case of XSLT and XSL-FO (both available through eDIB). But, for XProc and XQuery this name is not so intuitive. There is no other verb in English, which could describe such data processing step? I know that, in XForms, all actions are "processing steps" (e.g. insert, setvalue, delete, etc.), but there is also a container for them, namely "action" element.

Couldn't we find another more general name?

 
Claudius Teodorescu
http://kuberam.ro


Reply | Threaded
Open this post in threaded view
|

Re: Fw: XSLT extension action - continued

ther
How to change to digest mode for this mailing list?

Reply | Threaded
Open this post in threaded view
|

RE: XSLT extension action - continued

Philip Fennell-3
In reply to this post by claud108

Hello,

 
> "Transform" is a very nice name in case of XSLT and XSL-FO
> (both available through eDIB). But, for XProc and XQuery this
> name is not so intuitive.
 
In the cases of XSLT, XQuery and XProc, when these processes are applied to an instance data the result will be a a new structure (or at the very least the same structure (identity)) so I think the most common and broadly understood term to describe what has happened to the instance data is a transformation. Therefore, calling the action xf:transform would seem, to me, to be the most obvious choice.
 
 
Regards
 

Philip Fennell

Consultant
MarkLogic Corporation

Mobile +44 (0) 7824 830 866

email  [hidden email][hidden email]web    www.marklogic.com


This e-mail and any accompanying attachments are confidential. The information is intended solely for the use of the individual to whom it is addressed. Any review, disclosure, copying, distribution, or use of this e-mail communication by others is strictly prohibited. If you are not the intended recipient, please notify us immediately by returning this message to the sender and delete all copies. Thank you for your cooperation.

 
 
 

From: [hidden email] [[hidden email]] On Behalf Of Claudius Teodorescu [[hidden email]]
Sent: 02 September 2010 13:17
To: [hidden email]
Subject: Fw: XSLT extension action - continued


Hi,


"Transform" is a very nice name in case of XSLT and XSL-FO (both available through eDIB). But, for XProc and XQuery this name is not so intuitive. There is no other verb in English, which could describe such data processing step? I know that, in XForms, all actions are "processing steps" (e.g. insert, setvalue, delete, etc.), but there is also a container for them, namely "action" element.

Couldn't we find another more general name?

 
Claudius Teodorescu
http://kuberam.ro


Reply | Threaded
Open this post in threaded view
|

RE: XSLT extension action - continued

Nick Van den Bleeken-2

Hi,

 

That’s my view too. It doesn’t matter which processor you use, it is functional a transformation of the input data to the output data from XForms’ standpoint .

 

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: donderdag 2 september 2010 15:44
To: Claudius Teodorescu; [hidden email]
Subject: RE: XSLT extension action - continued

 

Hello,

 

> "Transform" is a very nice name in case of XSLT and XSL-FO

> (both available through eDIB). But, for XProc and XQuery this

> name is not so intuitive.

 

In the cases of XSLT, XQuery and XProc, when these processes are applied to an instance data the result will be a a new structure (or at the very least the same structure (identity)) so I think the most common and broadly understood term to describe what has happened to the instance data is a transformation. Therefore, calling the action xf:transform would seem, to me, to be the most obvious choice.

 

 

Regards

 

Philip Fennell

Consultant
MarkLogic Corporation

Mobile +44 (0) 7824 830 866

email  [hidden email][hidden email]web    www.marklogic.com

 

This e-mail and any accompanying attachments are confidential. The information is intended solely for the use of the individual to whom it is addressed. Any review, disclosure, copying, distribution, or use of this e-mail communication by others is strictly prohibited. If you are not the intended recipient, please notify us immediately by returning this message to the sender and delete all copies. Thank you for your cooperation.

 

 

 


From: [hidden email] [[hidden email]] On Behalf Of Claudius Teodorescu [[hidden email]]
Sent: 02 September 2010 13:17
To: [hidden email]
Subject: Fw: XSLT extension action - continued

 

Hi,



"Transform" is a very nice name in case of XSLT and XSL-FO (both available through eDIB). But, for XProc and XQuery this name is not so intuitive. There is no other verb in English, which could describe such data processing step? I know that, in XForms, all actions are "processing steps" (e.g. insert, setvalue, delete, etc.), but there is also a container for them, namely "action" element.

Couldn't we find another more general name?

 

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: XSLT extension action - continued

claud108
Hi,

Sorry for delay in answering.

So, to conclude, here is a new syntax for "transform" action:

<xf:transform
    type="xslt | xquery | xproc"
    exkf:processor="exist-client"
    origin="instance('i2')/pac"
    transformer="doc('test.xsl')"
    ref="instance('i0')/v1"
    param="instance('i2')/parameters"/>.

One can use also
param child elements which have 'name', 'ref'  and 'value' attributes
, as Nick suggested.

What do you think about @transformer? Is this a good name in English? Is is supposed to point to the XSLT stylesheet, XQuery script, or XProc pipeline.

Thank you,
 
Claudius Teodorescu
http://kuberam.ro

Reply | Threaded
Open this post in threaded view
|

RE: XSLT extension action - continued

Philip Fennell-3
Claudius,

Looks good.

> What do you think about @transformer?

An interesting and useful feature of XForms 1.1 is the 'resource' attribute/element that is used in xf:submission. It allows the form author to either declare 'statically' the URI of a resource (XML document) by using the resource attribute or allow the instance data to dynamically control the URI by using the xf:resource element. This could be applied to the xf:transform action to provide a very powerful and flexible way of controlling instance transformations.

The only other suggestion I'd like to make, as a counter argument to directly identifying the transformation, is that we also consider not using a URI in the action but to use the existing instance data and submission mechanisms to load the 'transform' into the form and then reference that 'instance' of a transform using a ref or bind attribute on the action. That way you get the advantages of the resource attribute/element that is already available in xf:submission, plus you get all the additional xforms-submission event trapping and even the ability to transform or generate transforms with other transforms.

Oh the power !!!


Regards

Philip Fennell
Consultant
MarkLogic Corporation
Mobile +44 (0) 7824 830 866
email  [hidden email]
web    www.marklogic.com

This e-mail and any accompanying attachments are confidential. The information is intended solely for the use of the individual to whom it is addressed. Any review, disclosure, copying, distribution, or use of this e-mail communication by others is strictly prohibited. If you are not the intended recipient, please notify us immediately by returning this message to the sender and delete all copies. Thank you for your cooperation.




From: [hidden email] [[hidden email]] On Behalf Of Claudius Teodorescu [[hidden email]]
Sent: 15 September 2010 08:36
To: Nick Van den Bleeken
Cc: [hidden email]
Subject: Re: XSLT extension action - continued


Hi,

Sorry for delay in answering.

So, to conclude, here is a new syntax for "transform" action:

<xf:transform
    type="xslt | xquery | xproc"
    exkf:processor="exist-client"
    origin="instance('i2')/pac"
    transformer="doc('test.xsl')"
    ref="instance('i0')/v1"
    param="instance('i2')/parameters"/>.

One can use also
param child elements which have 'name', 'ref'  and 'value' attributes, as Nick suggested.

What do you think about @transformer? Is this a good name in English? Is is supposed to point to the XSLT stylesheet, XQuery script, or XProc pipeline.

Thank you,


Claudius Teodorescu
http://kuberam.ro
Reply | Threaded
Open this post in threaded view
|

Fw: XSLT extension action - continued

claud108
Hi,


So, the new syntax could be:
<xf:transform
    type="xslt | xquery | xproc"
    exkf:processor="exist-client"
    origin="instance('i2')/pac"
    resource ="instance('i3')/stylesheet"
    ref="instance('i0')/v1"
    param="instance('i2')/parameters"/>.

Regards,
Claudius Teodorescu
http://kuberam.ro


Reply | Threaded
Open this post in threaded view
|

Re: XSLT extension action - continued

claud108
In reply to this post by Nick Van den Bleeken-2
Hi,

The new version of eXSLTForms
(http://sourceforge.net/projects/extxsltforms/files/) contains the transform
action, with @type="xslt".

The next version of eXSLTForms will contain transform action with @type="xquery
| xproc", through integration of eXSLTForms with eDIB
(https://sourceforge.net/projects/edib/files/), eXist Database in browser.

Claudius Teodorescu
kuberam.ro