OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From:	Michael Rys [SMTP:mrys@microsoft.com]
Sent:	Tuesday, June 19, 2001 4:28 PM
>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.

>Most of my XQuery constituency is not really interested in learning
>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.

>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 =
			<name><q:value-of select="$p/text()" /></name>
			<avgprice><q:value-of select="$a" /></avgprice>

...instead of:

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

That does not constiture an explosion in the complexity.