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

Re: Query on the XML graph

From: Michael Brundage <xquery@comcast.net>
Date: Mon, 09 Feb 2004 08:22:11 -0800
To: Murali Mani <mani@CS.UCLA.EDU>
Cc: Jim Tivy <jimt@bluestream.com>, Jiang Ming Fei <mfjiang@cse.cuhk.edu.hk>, "www-ql@w3.org 2" <www-ql@w3.org>
Message-ID: <BC4CF3B3.101C%xquery@comcast.net>

Hi Murali,

There's no idref() function in XPath 1.0.  The document you refer to is for
XPath 2.0.  And if you're going to use XPath 2.0, you may (depending on
whatever the final standard looks like) be able to introduce variable
bindings to overcome other limitations of XPath 1.0 I mentioned; see
[Personally I think this is a terrible idea - XPath should be kept simple,
without providing flow control and variable scope.]

If you were going to introduce step expressions for following ID/IDREF
edges, then I think it would best be expressed as another axis:

//Employee/@ReportsTo/id::Employee (equivalent to id(//Employee/@ReportsTo)

It's too bad that XPath 1.0 defines explicit names for axis under closure
(child -> descendant, parent -> ancestor) instead of just defining a
general-purpose closure operator.  If there were one, then you could write
things like closure(//Employee/@ReportsTo/id::*)


On 2/9/04 4:21 AM, "Murali Mani" <mani@CS.UCLA.EDU> wrote:
>> For example, given a structure containing Employee elements with ID and
>> ReportsTo attributes (typed as ID, IDREF, respectively), here are some joins
>> expressed using XPath 1.0:
>> (: all managers - i.e., all employees with at least one direct report :)
>> //Employee[//Employee/@ReportsTo = @ID]
> can I write the above query as also:
> Id(//Employee/@ReportsTo)
> by semantics of duplicate elimination, they will give the same result?
>> If XPath had an idref() function, you could do something like: :)
>> //Employee[count(idref(@ID)) >= 2]
> I thought there was an idref function?
> http://www.w3.org/TR/xquery-operators/#func-idref
>> //Employee[count(.//Employee)]
>> (: is trivial, but there's no way to recursively follow ID/IDREF edges :)
> I will tentatively suggest this:
> I think there should be step/(s) to navigate id/idref. Reasons are:
> 1. Now how do you traverse 2 idref edges in one path expression; it is not
> very easy..
> rough example: manager of managers:
> Id(Id(//Employee/@ReportsTo)/@ReportsTo)
> I think rather than the above, something like:
> //Employee/@ReportsTo->Employee/@ReportsTo->Employee might be easier to
> understand..??
> 2. We can think of extending recursive operators to idref traversal, and
> say:
> rough example: (This query can be written w/o recursion; but we can think
> of transitive closure as something like this..??)
> //Employee/(@ReportsTo->Employee)*
> best, murali.
Received on Monday, 9 February 2004 11:22:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:17:16 UTC