W3C home > Mailing lists > Public > www-zig@w3.org > September 2002

Re: Attribute architecture and nested attributes (path queries?)

From: Alan Kent <ajk@mds.rmit.edu.au>
Date: Wed, 11 Sep 2002 23:24:15 +1000
To: ZIG <www-zig@w3.org>
Message-ID: <20020911232415.J13412@io.mds.rmit.edu.au>

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

     PROX Element
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

     PROX Element

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.

Received on Wednesday, 11 September 2002 09:24:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:05 UTC