[Ex-plain] Attribute Searches

Robert Sanderson azaroth at liverpool.ac.uk
Thu Apr 11 20:19:15 CEST 2002


My specific proposal, being access, name and XML mapping:

Network Attr Set:

1        Host                    serverInfo host
2        Port                    serverInfo port
3        Protocol                serverInfo/protocol 
4        ProtocolVersion         serverInfo/protocolVersion  
5        Authentication          [see below]

Explain-- Attr Set:

1        Database Name           serverInfo database 
2        Attribute Value         map attr or map name
3        Attribute Type          map attr/type
4        Attribute Set           map attr/attributeSet
5        Record Syntax           recordInfo recordSyntax/name  
6        Element Set             recordSyntax elementSet/name

100      supportSearch           index/search
101      supportScan             index/scan
102      supportSort             index/sort
103      authoritative           explain/authoritative  [?]
104      localServer             ?


Authentication needs functional qualifiers (?) to say what sort of 
authentication it is.  eg:

NET 1 user
NET 2 password
E-- 1 group            (Other protocols that have group and open?) 
E-- 2 open             (Which would mean they should be NET 3 and 4) 

Authentication without a functional qualifier would imply 'is 
authentication required'

For support*, authoritative, localServer we could also have a 
format/strucutre attribute called 'boolean', with obvious implications.

100+ attributes are just boolean searches. 1-99 are term is text (but
probably exact key matching). Yes I know that there's nothing which says
that you should split things up, but heh when we want to add new terms 
they won't get all messed up with booleans and non booleans jumbled 
together.

See on for discussion on attribute type/value/set.

> > > > search = true PROX 0,equals,element,false,false
> > > > (
> > > >   (
> > > >     attributeType = 1 PROX 0,equals,element,false,false
> > > >     attributeSet = XD PROX 0,equals,element,false,false
> > > >     attribute = 3
> > > >   )
> > > I'm sorry, I don't understand your notation here.  Can you recast it
> > I just took it out of the standard.
> Well, put it back then!  >f'TUMPCH!<
> Where's that in the standard?

3.7.2.1 The Proximity Test
  Prox Distance,Relation,Unit,Ordered,Exclusion
Page 92 of the draft spec.

> > As an implementor I agree wholeheartedly with Ralph's comment that
> > it's much easier to do search for things in the record.  If you
> > don't need to add specific term handlers then so much the better.
> Just to check that I understand what point you're making: are you
> saying that when we introduce a search such as "thisServer", we should
> introduce a corresponding element that's physically present in the
> record?  Sounds stupid to me, but I guess I have no specific
> objection if that's how people want it.

If you only need to map a particular part of an XML record to a search 
term and check if they're identical, this is significantly easier than 
taking a term, parsing it into different sections (and having error 
checking if it doesn't parse properly), then applying the sections to 
different bits of the XML record or structure.

Currently this applies to 1=1 and 1=7.


> So your search would have to look like this:
[snip]
> Awful, isn't it?  :-)

Yup :)  It doesn't look significantly better in our syntax either (for 
obvious reasons)


> > I -could- (I think) implement this, but it's a significant pain.  If
> > it's a significant pain for me, it'll be a significant pain for
> Question: do you honestly think people are any less unlikely to
> implement this than what's currently documented?  Or is the chance of
> either getting implemented so vanishingly close to 0.0 that we're
> wasting our time even discussing it?  That's a serious question.

It depends on how proximity is handled by the server.  If it's already 
there, then they might as well. If it's not then either way is a pain as 
they need to write all the handlers for Proximity.  
In the case where they already have proximity, then the less parsing 
of terms they need to do the better.  If we have one bit of proximity, 
then might as well have more.   No human is going to construct such 
searches by hand on a regular basis (and if they do, they need their head 
examined) and a machine doesn't car how many PROXs are getting slapped 
together.

The only worry is reaching a server's maximum number of operators! :)

> > searches they support?  Useful for determining how widespread ZTHES
> > is (or any other attribute set)
> Ah, you got me in my voonerables :-)  Yes, I'd love to be able to ask
> that kind of question about Zthes (note the capitalisation, by the
> way.)

It was a bit low, but I thought it'd make the point ;)

Rob

-- 
      ,'/:.          Rob Sanderson (azaroth at liverpool.ac.uk)
    ,'-/::::.        http://www.o-r-g.org/~azaroth/
  ,'--/::(@)::.      Special Collections and Archives, extension 3142
,'---/::::::::::.    Twin Cathedrals:  telnet: liverpool.o-r-g.org 7777
____/:::::::::::::.              WWW:  http://liverpool.o-r-g.org:8000/
I L L U M I N A T I







More information about the Ex-plain mailing list