- From: Jonathan Borden <jborden@mediaone.net>
- Date: Thu, 3 Jan 2002 16:38:30 -0500
- To: "David Carlisle" <davidc@nag.co.uk>, "Jonathan Robie" <jonathan.robie@softwareag.com>
- Cc: <www-xml-query-comments@w3.org>, <xml-dev@lists.xml.org>
Jonathan Robie wrote: > At 03:25 PM 1/3/2002 -0500, Jonathan Borden wrote: > >One can always introduce a new/XML syntax, I would favor: > > > >3) updating XSLT including XPath 2.0 as the XML syntax 'version' of XQuery, > >that is to say any features of XQuery not included in XPath 2.0 should be > >included in XSLT 2.0 (well it already has element constructors etc). Is this > >feasable? > > Possibly. But some of this is hard. XSLT tends to construct things top > down, and XQuery constructs things bottom up, for reasons that make perfect > sense in each language, which means the element constructors are different. I am not at all sure this is an insurmountable issue, and much depends on the style of XSLT that is used. > Updates don't work well in XSLT since it clearly separates the input tree > from the output tree. A somewhat long time ago (i.e. circa 2000) I wrote a little XML editor which compiled itself into XSLT http://www.openhealth.org/editor/. Work on this was merged into the XUpdate progect of xml:db http://www.xmldb.org/xupdate/xupdate-wd.html. I think that the XSLT _syntax_ is perfectly capable of _expressing_ updates, and any issues are left to implementations. But moreover, most XSLT implementations include a function that casts a result-set into a node-set, so this issue is well known and hopefully such a cast operator could be made a standard part of XSLT 2.0. In any case I think there probably is not a need to have both an XML syntax for XQuery and XSLT 2.0, as query and transform are really two heads of the same coin. Jonathan
Received on Thursday, 3 January 2002 16:39:43 UTC