- From: Alan Kent <ajk@mds.rmit.edu.au>
- Date: Wed, 11 Sep 2002 23:24:15 +1000
- To: ZIG <www-zig@w3.org>
On Wed, Sep 11, 2002 at 02:04:02PM +0100, Robert Sanderson wrote:
> > You need something like a PROX operator with an attribute list:
> >
> > /author/firstname=John
> > Within-the-same /author
> > /author/lastname=Smith
>
> Element is a valid proximity unit already. ZeeRex uses it, for example,
> to be able to search for attribute combinations as opposed to attributes
> anywhere in the document.
The disadvantage is "Element" is not fully precise. If I expand the above
example
/body/author/firstname=John
PROX Element
/body/author/lastname=Smith
Does John and Smith need to be under the same body element or same author
element? How do I express both concepts? (Simple answer may be "tough luck").
Then what about
/a/b/c=John
PROX Element
/a/b/d/e=Smith
Does it mean same /a or same /a/b or does it not make sense since
/a/b/d/e is at a different depth to /a/b/c? etc.
It is also worth remembering that the attribute path is an *attribute
path*, not an element path (I was just using XPath syntax as a shorthand).
So do I use "PROX element" for nested attribute values?
But I agree, its probably the best solution given Z39.50 as it is.
Its just a matter of saying PROX-element means the lowest element
in the path common to both operands.
Evil thought: does ZeeRex support nested attributes? These are normally
specified using 'complex' in an attribute list, not just a type/value pair.
I guess you can just repeat multiple values for the same type.
Alan
Received on Wednesday, 11 September 2002 09:24:54 UTC