[Ex-plain] Attribute Searches
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
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
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?
126.96.36.199 The Proximity Test
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:
> Awful, isn't it? :-)
Yup :) It doesn't look significantly better in our syntax either (for
> > 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
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
It was a bit low, but I thought it'd make the point ;)
,'/:. Rob Sanderson (azaroth at liverpool.ac.uk)
,'--/::(@)::. 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