- From: Jonathan Robie <jonathan.robie@softwareag.com>
- Date: Thu, 03 Jan 2002 10:19:51 -0500
- To: David Carlisle <davidc@nag.co.uk>, www-xml-query-comments@w3.org
- Cc: xml-dev@lists.xml.org
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: <foo><?fmt font="bold"?> <!-- The above PI is for my favorite formatting engine --> </foo> 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: <foo> { processing-instruction("fmt", font="bold"), xml-comment("The above PI is for my favorite formatting engine") } </foo> 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 given installation. 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"?> <xquery xmlns="http://www.w3.org/TR/XQuery/2001-12-20/"> count( //table ) </xquery> 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 >boolean false(). 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. Jonathan
Received on Thursday, 3 January 2002 10:20:19 UTC