RE: XQuery & XSLT was RE: Verboseness - XML Syntax for XQuery1.0(XQueryX)

[Michael Rys <mrys@microsoft.com>]

> >I don't think that the template body format is appropriate for the
user 
> >communities that are most likely to use XQuery.
> 
> How does this community differ from the XSLT one? I am an 
> XSLT user and likely to be an XQuery user when viable 
> implementations become available. They are both likely to be 
> important parts of the XML programmers toolkit.

I would argue that there is a much larger user-base out there that has
no knowledge of XSLT that will end up using XQuery (many database
developers etc).

> >Most of my XQuery constituency is not really interested in learning
XSLT
> >syntax but prefers the XQuery syntax.
> 
> This constituency must at this stage consist, in large part, 
> of the working group. As I've said, I'm not proposing the 
> wholesale adoption of XSLT, just consistency where they 
> overlap. This may imply changes to XSLT for 2.0, because as 
> I've mentioned in the past, XQuery does include some useful 
> improvements which would benefit XSLT.

Sorry, but I do not speak for the working group. Therefore the
constituency that we talk about is not the same...

I think what would be really helpful is feedback on what you can accept
in terms of changes to XSLT and XPath to keep semantic consistency with
XQuery. That's what is much more of an issue in the end then the syntax.

> >Is this really a problem? I find human readability and writeability
to 
> >be more important goals. Having XML-based constructor functions for 
> >elements and attributes breaks readability and writeability 
> more than 
> >the current constructors.
> 
> If you know how to write XML, the XML-based constructor 
> format is relatively intuitive. In this case, writing badly 
> formed XML-a-like syntax (e.g. unquoted attribute value 
> templates) is counter-intuitive. If you do not know how to 
> write XML, then you are going to have to learn it in order to 
> create the results part of the query.
> 
> Regarding "a concise, easy to read and write declarative 
> language.", I'm not proposing anything overly fine grained.
> 
> For example:
> 	(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.

This does not really help either the human writer nor the parser. You
still have to parse the expressions and you mix and mismatch syntactic
concepts. Not really useful in my opinion.

Best regards
Michael