- From: Norman Walsh <ndw@nwalsh.com>
- Date: Wed, 25 Jun 2008 14:08:41 -0400
- To: public-xml-processing-model-comments@w3.org
- CC: Michael Kay <mike@saxonica.com>
- Message-ID: <m23an1e6ae.fsf@nwalsh.com>
[ For some reason I never received this, though it does appear in the archives.]
> Michael Kay wrote:
> (ACTION A-369-03)
>
> I was asked to convey the XQuery WGs comments on the XProc specification,
> and in particular on the mechanism for invoking XQuery from XProc.
> (Formally, these are comments from the joint XQuery/XSL WGs, but the XSL WG
> had already made its own comments on the parts of the spec relevant to XSLT
> - at any rate, on a previous draft.)
>
> The comment is in two parts: (a) an email from Andrew Eisenberg, and (b) my
> summary of the WGs discussion of that email and other observations.
>
> First, Andrew's email, which the WG largely endorsed:
>
> http://lists.w3.org/Archives/Member/w3c-xsl-query/2008Jun/0000.html
Unfortunately, this message is in a member-only archive and our WG
operates in public. I have replied privately to Andrew with my
thoughts asking him to please publish that message to the public
comments list.
> We noted that Andrew is proposing to make it an error if the query returns
> anything other than document nodes (presumably representing well-formed XML)
> or element nodes. An alternative would be to allow the query to return other
> values (for example, the integer 17) and turn these into XML documents by
> some defined wrapping process.
I don't feel strongly about it. Feedback from the XQuery WG on what
they believe is the right answer would be appreciated.
> The other observation made in discussion was about the requirement for the
> pipeline to be able to generate a query that is then executed. I think this
> is a common scenario, for example a pipeline might start with an XForms
> instance representing user input from a browser form, and use XSLT or XQuery
> to translate this instance into an XQuery which is then executed against an
> XML database. The fact that the only things that can flow between steps in a
> pipeline are XML documents, but an XQuery is not an XML document, clearly
> makes this difficult. XQueryX might provide some kind of solution, but it is
> not exactly an easy format for user applications to generate. The current
> solution in the spec is to construct a query as text, and then wrap this in
> a c:query element: the need for double-escaping is likely to make this very
> error-prone, especially as XQuery's escape conventions are by design very
> similar to those of XML. Personally, I think that because a large subset of
> queries are in fact well-formed XML, we ought to be able to define some kind
> of subset of XQuery that acknowledges this subset of the language and allows
> it to be passed around directly (I think Orbeon does something like this
> today). But that goes well beyond anything the WG has discussed.
I think our spec may be misleading on this point. I had imagined that c:query
was a wrapper around some well-formed XML. So you might write:
<c:query>
default element namespace="http://www.w3.org/1999/xhtml"
<html>
<head>
<title>Dumb query</title>
</head>
<body>
</body>
</html>
</c:query>
Is it really the case that there are queries which aren't well-formed
XML? And can we just not support them, or are they common?
Be seeing you,
norm
--
Norman Walsh <ndw@nwalsh.com> | Some people do their laundry in emacs,
http://nwalsh.com/ | but I find typing ^C-^X-^W-q-L-TT to
| add the fabric softener to be a bit
| cumbersome.-- rlr@panix.com
Received on Wednesday, 25 June 2008 18:09:19 UTC