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

[Dylan Walsh <Dylan.Walsh@Kadius.Com>]

> From:	Jonathan Robie [SMTP:Jonathan.Robie@SoftwareAG-USA.com]
> Sent:	Tuesday, June 19, 2001 6:12 PM
> 
>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.

The current format does not use real XML elements as far as I
understand.

>>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 

I provided a rough example in another post in this thread. See the end
of this message.

>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.

I'm not suggesting anything of the sort. What I'm proposing it that the
result part of the query consist of real XML elements with the say
elements in the query namespace to select parts of the result data to
insert and using attribute value templates for attributes in a manner
similar to XSLT.

>>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.  

Agreed. Errors in XQuery expression would only be checked by the
implementation, as XPath errors are with XSLT.

>>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. 

The XSLT version you provide is an example of using XSLT exclusively to
perform the same task as an XQuery.
I'm suggesting using elements for the results. 

>>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. 

The element construction syntax for both would in fact be XML.

>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. 

Here is what I suggested:

	(This is a rough sample - I'm not familiar with the ins & out of
XQuery grammar)

<q:query xmlns:q="http://www.w3.org/2001/06/xquery">
	<q:for>$p IN distinct(document("bib.xml")//publisher)</q:for>
	<q:let>$a := avg(document("bib.xml")//book[publisher =
$p]/price)</q:let>
	<q:return>
		<publisher>
			<name><q:value-of select="$p/text()" /></name>
			<avgprice><q:value-of select="$a" /></avgprice>
		</publisher>
	</q:return>
</q:query>

...instead of:

	FOR $p IN distinct(document("bib.xml")//publisher)
	LET $a := avg(document("bib.xml")//book[publisher = $p]/price)
	RETURN
		<publisher>
			<name>{ $p/text() }</name>
			<avgprice>{ $a }</avgprice>
		</publisher>

That does not constiture an explosion in the complexity.