- From: Jonathan Robie <jonathan.robie@softwareag.com>
- Date: Thu, 03 Jan 2002 12:03:10 -0500
- To: Elliotte Rusty Harold <elharo@metalab.unc.edu>, ht@cogsci.ed.ac.uk (Henry S. Thompson), David Carlisle <davidc@nag.co.uk>
- Cc: www-xml-query-comments@w3.org, xml-dev@lists.xml.org
At 11:49 AM 1/3/2002 -0500, Elliotte Rusty Harold wrote: >At 10:46 AM -0500 1/3/02, Jonathan Robie wrote: >>At 10:09 AM 1/3/2002 -0500, Elliotte Rusty Harold wrote: >>>There are two ways to fix this: >>> >>>1. The XSLT solution: Make all XQueries complete, well-formed, XML documents >> >>XQueryX does that. Personally, I'm not sure that XQueryX is something >>that users would want to write, so it is not the solution to David's problem. > >I agree, but that's because in large part XQueryX was deliberately not >designed as a human authorable, human-readable syntax. I think XQueryX >could be redone in a more user-friendly form if that were desired. But doing this would require major new work, and would set back the schedule for XQuery 1.0 significantly. Especially since the resulting syntax would be syntactically similar to XSLT, but would have to be different because of the optimizability and type-safety goals of XQuery. At that point we wind up having to justify every place that we differ from XSLT, resulting in prolonged discussion in the joint task force and on various mailing lists such as this one, and XQuery 1.0 can get bogged down completely. >>>2. The XPath solution: Make all XQueries look nothing like XML >>>documents; i.e. no tags, no elements, no attributes >> >>Computed element constructor syntax allows this. Here is Henry's example >>done in computed element constructor syntax, where the wrapping element >>is in the XML document, and nothing in the query per se looks like XML: > >I haven't seen this before. It does look like a possible solution. >However, you still need to eliminate the non-computed element constructor >syntax, which will still cause all the problems of user confusion on its >own, even if a non-confusing alternative exists. I'm not convinced that we need to remove the angle-bracket notation for element constructors. In queries that are not embedded in an XML document, I don't think that they cause users to be confused. In queries that *are* embedded in an XML document, I think they cause users to be confused only if the user looks at the text of the document. If a system wants to create readable queries within documents, it can translate the syntax to computed element constructor syntax before writing the document. The angle-bracket notation for constructors is convenient for people who like to copy existing document text to a query and add dynamic expressions. Jonathan
Received on Thursday, 3 January 2002 12:40:01 UTC