W3C home > Mailing lists > Public > www-ql@w3.org > January to March 2004

RE: Questions related to XPath 2.0

From: Kay, Michael <Michael.Kay@softwareag.com>
Date: Sun, 25 Jan 2004 18:30:33 +0100
Message-ID: <37B64F4BA60E9E4FB9F60929E05980242877F4@DAEMSG03.eur.ad.sag>
To: "Murali Mani" <mani@CS.UCLA.EDU>, <www-ql@w3.org>

> I had 3 questions related to XPath 2.0
> 
> 1. What is the rationale behind including for expressions, 
> conditional expressions etc in XPath 2.0? From a glance, I 
> would have preferred if XPath only allowed us to specify 
> patterns, and XPath engine will return all the occurrences of 
> the pattern (say in document order etc).. I might have 
> preferred if these things were in XQuery/XSLT and not in XPath..
> 
> But I believe there should have been a rationale for this? 
> Can you summarize/point me to that?

There is an XPath 2.0 requirements statement at
http://www.w3.org/TR/xpath20req/ which is the nearest you will get to an
official rationale. Unfortunately a requirements statement typically
doesn't say why one requirement has been included and another has not.
Section 2.2  states a requirement for conditional expressions, and for
expressions are provided to satisfy requirements such as 2.5 (e.g.
summing over price times quantity) and 4.4 (adding a list data type).

A use case for conditional expressions is in XSLT sort keys, where you
want to say 

<xsl:sort select="if (@price) then @price else @value"/>

This is very hard to achieve in XSLT 1.0.

Summing over price times quantity is one use case for "for" expressions;
another is performing a join. But as soon as you add a sequence data
type to support XML Schema lists, you need to provided a set of basic
operations on sequences and mapping is obviously one of these basic
operations, found in every language that supports list processing.

Of course there was much debate about this. Some people wanted the XPath
language to be smaller than it is, and some wanted it to be larger, and
the current level is there not because of any documented rationale, but
because it was the most widely acceptable compromise between different
people's views. In my view, though, it's about right. I would personally
have stopped short of including range variables: i.e. I would have gone
for a simpler "for" expression that binds the context item. But people
handling data-oriented XML felt the language should be relationally
complete, which does require range variables to do arbitrary joins.

> 
> 2. I was looking at fn:id (string) and fn:idref (string). How 
> do I use it, say if I get a list of values of idref 
> attributes. An example that I may think of is a schema (rough 
> DTD) like:
> 
> <!ATTLIST Professor (pname, office, pid)>
> <!ATTLIST Student (sname, major, advisor)>
> 
> advisor is an IDREF attribute, pid is ID attribute.
> 
> I want to do something like:
> Student [@major='CS']/@advisor->Professor/@pname

I'm sorry, but giving me an expression using an operator whose semantics
aren't defined isn't a good way of explaining your requirements. What's
your input and what's your desired output?
> 
> Basically names of advisors of CS majors. How do I write in 
> XPath, can I do it w/o using ForExpr
> 
> 3. Another thing I noted is: When I look up fn:id, the spec 
> does not mention whether the result will contain duplicate 
> nodes. I see that the spec mentions for fn:idref that the 
> result will not contain duplicate nodes. I hope this was just 
> overlooked?
> 

I would have thought it was fairly obvious from the description of the
fn:id() function that it cannot contain duplicate elements, but you're
correct that it doesn't explicitly say so. If you want such comments to
be taken into account you should send them to the public-qt-comments
list at w3.org.

Michael Kay
Received on Sunday, 25 January 2004 12:30:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 22 July 2006 00:10:19 GMT