- From: Kay, Michael <Michael.Kay@softwareag.com>
- Date: Sun, 25 Jan 2004 18:30:33 +0100
- 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 UTC