Re: New XPath extension function called xslt()

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 <Philip.Fennell@marklogic.com>
To: Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>; Claudius Teodorescu <claud108@yahoo.com>
Cc: "www-forms@w3.org" <www-forms@w3.org>
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: philip.fennell@marklogic.com
Mobile: +44 (0)7824 830 866 



-----Original Message-----
From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On Behalf Of Nick Van den Bleeken
Sent: Thursday, April 15, 2010 1:44 PM
To: Claudius Teodorescu
Cc: www-forms@w3.org
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
nick.van.den.bleeken@inventivegroup.com
http://www.inventivedesigners.com
Linked in


> -----Original Message-----
> From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On Behalf
> Of Claudius Teodorescu
> Sent: donderdag 15 april 2010 14:36
> To: Nick Van den Bleeken
> Cc: www-forms@w3.org
> 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.
--

Received on Thursday, 15 April 2010 21:32:04 UTC