- From: Michael Rys <mrys@microsoft.com>
- Date: Tue, 19 Jun 2001 10:08:45 -0700
- To: "Dylan Walsh" <Dylan.Walsh@Kadius.Com>, <xml-dev@lists.xml.org>, <www-xml-query-comments@w3.org>
> >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
Received on Tuesday, 19 June 2001 13:16:06 UTC