RE: XSLT extension action - continued

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
nick.van.den.bleeken@inventivegroup.com <mailto:nick.van.den.bleeken@inventivegroup.com>
http://www.inventivedesigners.com<http://www.inventivedesigners.com/>
Linked in<http://be.linkedin.com/in/nvdbleek>

From: Philip Fennell [mailto:Philip.Fennell@marklogic.com]
Sent: woensdag 1 september 2010 13:27
To: Claudius Teodorescu; Nick Van den Bleeken
Cc: www-forms@w3.org
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  Philip.Fennell@marklogic.com<mailto:Philip.Fennell@marklogic.com>
web    www.marklogic.com<http://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: www-forms-request@w3.org [www-forms-request@w3.org] On Behalf Of Claudius Teodorescu [claud108@yahoo.com]
Sent: 01 September 2010 11:04
To: Nick Van den Bleeken
Cc: www-forms@w3.org
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 by MailScanner, and is
believed to be clean.
--