W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2002

Re: [xml-dev] XPath 2.0 - how much of XQuery should it include?

From: Jeni Tennison <jeni@jenitennison.com>
Date: Mon, 13 May 2002 06:14:36 +0100
Message-ID: <911801402069.20020513061436@jenitennison.com>
To: scott_boag@us.ibm.com
CC: public-qt-comments@w3.org
Hi Scott,

> XPath:
> 1) An addressing mechanism into trees and sequences.
> 2) Constructs sequences of values.
> (And, yes, it might be interesting to try and separate (1) into a
> subset, though I have my doubts given complex predicates).
> 1) Constructs trees.
> The separation of these responsibilities helps to reduce the
> complexity of either. Each is a tool tuned to it's respective task.
> Each can be expected to have some redundant mechanism, such as
> iteration and conditional evaluation.

Yes, Mike's explained that distinction, and I can see that it is
internally consistent one to make. I'm sure that there are those in
the WG that have made the following points, but just in case...

1. When you're writing the code, it's much easier to work out how to
achieve a task based on what you want to do rather than what you want
to do it to. The thought process "OK, I want to have a loop that
creates a sequence of atomic values, so I have to do that using XPath,
which means using a for expression" is less intuitive than the thought
process "OK, I want to loop, so I need to use xsl:for-each". I think
that we'll often get situations where users will know how to achieve a
task when using XSLT but not understand how to achieve the comparable
task when using XPath (and vice versa), particularly since the
approach to looping is fairly different.

2. I don't buy the separation-reduces-complexity argument. XPath is
certainly more complex, and XSLT is no less complex with the current
separation. Aside from the ability to create an atomic value, what
savings have been made on the XSLT side due to the extra complexity of

3. Mike's made an argument that the tools are easier to write because
they can focus on the optimisation of the XPath side of the equation.
But XQuery has a single approach:

  for $i in $list                 for $i in $list
  return <foo />                  return 'foo'

Aside from syntax, I can't see a difference between these queries and
the XSLT:

  <xsl:for-each select="$list">   <xsl:for-each select="$list">
    <foo />                         <xsl:item select="'foo'" />
  </xsl:for-each>                 </xsl:for-each>

Perhaps XQuery implementers have some ideas about telling the
difference that could help.
4. There are things that are lacking in the XPath version of sequence
manipulation that are present in the XSLT version of sequence
manipulation that I believe will make the XPath version a lot harder
to deal with. In particular, I'm thinking of variable assignment and
the ability to keep track of the context position of an item in a
sequence. I think that people are going to have to create their own
functions so that they can use XSLT variable assignment to get around
those problems, and I think that's a bad idea on usability grounds,
and because I think function use should be a choice rather than a
necessity in a programming language.

> While your posts have been thought provoking, in terms of seeing the
> hideously complex, I think you should keep in mind that you're still
> seeing very intermediate results. Hopefully some functionality is
> yet to be pruned, some seemingly complex functionality needs
> polishing, and a few bad (or incomplete) ideas need to fixed.

Sure. I understand from personal experience how frustrating it is to
receive feedback on areas that you already *know* need work. I'd like
to direct comments on the areas that you're interested in getting
feedback on; on the other hand, it seems risky to wait until the WDs
become Candidate Recommendations before I comment on a feature that
doesn't seem right to me -- I think you'd be even more irritated by my
comments if they came later in the process. Perhaps it would help, in
the drafts or separately, for you to list those sections that you're
pretty certain are representative of how you intend things to be, so
that we can focus our reading and comments on them. Or perhaps there's
a particular style of comments that you'd prefer?

> The question is, do we need a general change of direction? Given the
> many opinions and 3 years (or whatever it's been) of discussion, I
> actually think we're doing fairly well, and the results will be a
> healthy design balance, with very positive connotations for the Web.
> Certainly the results will not be perfect. But I think we're on a
> pretty reasonable track, with light being seen at the end of the
> long tunnel.

I'm very glad that you feel like that; I'd be worried if the driver
was wandering through the train checking the map. Sitting here in the
carriage, I'm seeing increasing unease on the faces of many of the
other passengers as the names of stations flash past. Perhaps we all
got on the wrong train; perhaps this is an alternative route we don't
know about and once we emerge from the tunnel we'll be reassured; or
perhaps the driver didn't realise that the train was supposed to be
heading somewhere else. Whichever case it is, it's not going to get
resolved by us hiding behind our newspapers hoping that everything's
OK or that someone else is talking to the crew.

Please understand: by making comments at all, I'm trying to be
constructive by supplying an external, user perspective, not trying to
make trouble by destroying the delicate balance of compromises that
have led to the current design. I suggest alternatives because I
believe that's more useful than abstract critiques, not because I have
particularly fixed ideas about what a solution should look like. I
know that the WGs have an incredibly difficult task on their hands,
and that you've all put in a lot of work to get to where you are now,
and I do appreciate that effort, even if I don't agree with the



Jeni Tennison
Received on Monday, 13 May 2002 01:14:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:56:42 UTC