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
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 29 October 2009 06:12:22 GMT