Lists Home |
Date Index |
> >>>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.
Is there a possibility of a solution in which the XML-like syntax becomes
pure XML, and is regarded as a preprocessor syntax, so that a query written
as a well-formed XML document (using element constructors for elements,
processing instructions for PIs, and comments for comments) can then be
translated mechanically into an XQuery expressed as a Unicode string, which
itself uses no XML-like constructs?
This would mean the Unicode-XQuery syntax wouldn't need to include all the
XML-like constructs, greatly simplifying parsing, while the XML-XQuery
syntax would be pure XML and therefore manipulable using all XML tools. The
translation from XML-XQuery to Unicode-XQuery could almost certainly be
specified and indeed implemented in XSLT.
I think this would also satisfy the real user requirement behind XQueryX.
OK, there's timescales. But the reason we put drafts out for comment is to