Lists Home |
Date Index |
At 11:46 AM 1/3/2002 +0000, David Carlisle wrote:
>I am very surprised that the W3C is proposing to standardise a language
>that uses syntactic constructs such as
><...> ... </...>
><!-- ... -->
><![CDATA[ ... ]>
>in a format which is _not_ XML.
>This just seems guaranteed to ensure user confusion.
The basic idea is that any construct in XQuery that looks like XML is a
constructor for the same construct. Suppose XQuery used an XML syntax. What
would the following query construct:
<!-- The above PI is for my favorite formatting engine -->
In the current syntax, the above constructor creates a PI and a comment
within the element. If XQuery were an XML syntax, we would have to create
comments and PIs some other way, eg:
xml-comment("The above PI is for my favorite formatting engine")
I prefer to be able to use the straight XML syntax, as in the current WD.
>One of the main benefits of using XML as a syntax for a new text based
>format is that lots of tricky i18n and encoding issues are dealt with at
>that level. By choosing not to be XML, Xquery loses these benefits and,
>as far as I can see in the drafts, proposes no alternative.
My assumption has been that queries would be written in Unicode. It is also
possible to embed an XQuery in an XML document, so that the XML processor
manages the encoding, expands out character entities, etc. However, many
query environments will not need this, either because queries are written
in Unicode with an appropriate keyboard driver (I always have several
installed ;->), or because internationalization is not a concern for the
I think that requiring that all queries be embedded inside an XML document
is overkill. In the 80/20 case, queries can be written in Unicode or
converted to Unicode. However, perhaps it would make sense to require
XQuery processors to also accept queries in an XML document that simply
embeds the query in an element:
<?xml version="1.0" encoding="UTF-8"?>
count( //table )
That would be very easy to specify, and easy for implementations to
support. If the idea generates enthusiasm on this list, I can raise the
idea in the WG.
>In XSLT I can write my stylesheet in any encoding I want, but still
>query the full range of XML documents.
How important is it to be able to write queries in any encoding you want?
Must this be part of the query language per se, or could it be left up to
the environment? If an environment supports a non-Unicode encoding, is it
too burdensome to ask it to convert text to Unicode?
>It is very common to XML-quote the apostrophes used to delimit Xpath
>strings in order to fit the expression into an XML attribute, but note
>this is using the XML entity or character reference syntax on Xpath
>delimiters, something that is not permitted in Xquery. [ !!! SNIP !!!]
>but usually when people write Xpaths they write them as they appear in
>XML/XSLT in which case the above is a legal Xpath which is just
>an XML-encoded version of 'a'='b' which is a legal expression with value
True, but is this difference really interesting? I would hope that the XSLT
author knows exactly what they are doing when they do that kind of XML
quoting, and should not surprised that this does not occur in the absence
of an XML processor.
>Changing Xquery to be an XML format would not require so many changes in
>the document. The parts of the grammar copied from the XML grammar could be
>removed. Incidentally those parts highlight another problem with
>copying rather than using XML, they use the character productions from
>XML 1.0 but XML 1.1 is (perhaps) going to change them. If Xquery
>referenced XML it would be a lot more straightforward managing the
>issues related to unicode 3.x characters in QNames. (At least it would
>be XML's problem rather than Xquery's)
Actually, I think this would be a fairly significant change. In XQuery, it
is important that element constructors are expressions that have a
well-known type, not a black-box way of creating nodes. Element
constructors should be present in both the grammar and the type system. An
element constructor is just another kind of expression, with a well-known
type, and that's quite significant in the design of XQuery.