Re: XQuery & XSLT was RE: Verboseness - XML Syntax for XQuery 1.0(XQueryX)

[Jonathan Robie <Jonathan.Robie@SoftwareAG-USA.com>]

Hi Dylan,

I've removed the XML Query Comments list from my Cc:, because I am only 
able to post replies that are approved by the Working Group to that list.

At 12:10 PM 6/19/2001 +0100, Dylan Walsh wrote:

>There is nothing more confusing than having two similar but subtly
>different syntaxes to remember. XQuery serves a different purpose to
>XSLT and needs a different syntax to reflect these differences. However,
>where the two standards overlap they should be more consistent.

Absolutely. That's why we are working together on XPath 2.0.

>(2), I believe the XSLT format should be used.
>It has been stated more than once, that the workings groups are
>co-ordinating their efforts for consistency, but based on
>http://xmlportfolio.com/xsltuk/slides/ that does not appear to be
>working perfectly.

I do not know when the above presentation was written, but you may have 
noticed that it uses the February 15th syntax of XQuery, and that one of 
the main changes between the February 15th Working Draft and the June 7th 
Working Draft was a set of major changes to the grammar that make it much 
more compatible with XPath, and we also added James Clark to the list of 
editors.

You complain particularly about the element construction syntax. Perhaps 
you noticed that we no longer use the element construction syntax Evan has 
in his slides.

>In particular, I believe the XSLT template body format should be used for
>query results.

I need more detail on this to understand what you want. Let me ask you a 
few questions based on one of Evan's examples 
(http://xmlportfolio.com/xsltuk/slides/Q18b.html).

In the new XQuery syntax, it looks like this:

FOR $h IN //holding
RETURN
         <holding>
                 { $h/title }
                 {
                         IF ($h/@type = "Journal")
                         THEN $h/editor
                         ELSE $h/author
                 }
         </holding>
SORTBY(title)

Note that the curly braces indicate expressions to be evaluated, as opposed 
to literal content.

I do not know how to make XQuery use XSLT template syntax for constructing 
results without making XQuery simply be XSLT syntax for everything in 
preference to XQuery syntax. After all, any XQuery expression can occur in 
the return clause of a FLWR expression, and XSLT can not represent all of 
these expressions.

For instance, Evan provides the following equivalent to the above query:

<xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
   <xsl:template match="/">
     <xsl:for-each select="//holding">
       <xsl:sort select="title"/>
       <holding>
         <xsl:copy-of select="title"/>
         <xsl:choose>
           <xsl:when test="@type='Journal'">
             <xsl:copy-of select="editor"/>
           </xsl:when>
           <xsl:otherwise>
             <xsl:copy-of select="author"/>
           </xsl:otherwise>
         </xsl:choose>
       </holding>
     </xsl:for-each>
   </xsl:template>
</xsl:transform>

How would you suggest we combine the two syntaxes for element construction?

>My understanding of the point of XQuery was that it provides querying
>across collections of XML documents, with new features for this task and
>better scope for optimization than XSLT.
>Making it more "SQL-like" seems pointless to me, as the language is
>different anyway, and the model is not relational. It uses different
>keywords and different syntax.

I agree with both you and Mike, depending on what is meant by "SQL-like". 
Mike's point, as I understand it, is that there are certain kinds of 
"SQL-like" operations people are used to performing on their data, and 
XQuery lets them do this kind of operation with the richer data model 
provided by XML.

I agree that making the syntax more SQL-like is pointless as an exercise in 
itself, and that the XQuery syntax will have differences due to the 
different data model. For FLWR expressions, which do provide functionality 
similar to SQL, it is useful to have a syntax that is readily 
understandable to SQL programmers. It is also vital to have this syntax be 
compositional with respect to the rest of XQuery.

> >>True, but I think it should be, or that they should have a human
> >>writeable XML syntax available as well.
>
> >How important is this, and why is it important? Why would humans prefer
>to write queries in an XML syntax?
>
>The users editor can ensure well-formedness.

True, but that won't keep you from making many very common mistakes, such 
as referencing variables that have not been declared. Personally, I do not 
find that using an XML editor for writing XSLT prevents me from making very 
many mistakes, except at the typo level.  This is especially true if I am 
doing well-formed XML rather than valid XML.

Let's be very concrete. Suppose I type the following badly-formed query:

     FOR $h IN //holding

My XQuery parser can tell me that I am missing the return clause. I could 
make the same mistake in XSLT-like syntax, and then an XML parser could 
tell me the same thing. Well-formedness is not enough to catch this error, 
but the resulting query would not be valid according to the schema or DTD. 
That would allow an XML editor to catch many, but not all, of the errors 
that an XQuery parser can catch. That means you probably want an XQuery 
parser in an editing environment anyway, because you want the parser to be 
able to catch all the syntactic errors that can be detected at parse-time. 
If this is true, I'm not sure that the XML parser buys you all that much, 
especially given the fact that the source files for XQuery parsers are 
already available.

>The syntax for results is itself XML, making it more intuitive.

Can you give me examples where this is more intuitive? In the XSLT 
equivalent of the query I present above, I find that I have a bit of a 
figure/ground problem, since the syntax of the data looks a lot like the 
syntax of the programming language. I find that XQuery is more intuitive 
precisely because the syntax of our expressions can easily be distinguished 
from the syntax of XML constructors used in the expressions.

>The syntax for results can be similar to that of XSLT, meaning
>programmers only have to learn one syntax.

That's an advantage if the syntax is precisely that of XSLT, but arguably a 
disadvantage if the syntax is similar to XSLT but not quite the same. 
Languages that are different should look different. I think that XPath 
should be the same for both languages, but I'm not at all convinced that 
XML node construction should use the same syntax for the two languages.

However, it's easy to prove me wrong. Write an XML syntax for XQuery that 
is readable and writeable for humans, and which posesses the virtues you 
outline above. I don't think that I would be able to do so, and I have, in 
fact, tried to do so a few times. But there may be people on this list who can.

Jonathan

These are my opinions right now. They may be quite different from the 
opinions of Software AG, the W3C XML Query Working Group, or the opinions 
that I will have after reading and considering your response.