On Tue, 24 Sep 2002, Mike Taylor wrote:
> > From: Ray Denenberg <[log in to unmask]>
> > The point [of the document we're all arguing about] is that there
> > will be a way to express the intended semantics of the index.)
> I honestly do not imagine that one single person in the whole world
> will look at this document in order to understand the semantics of a
> CQL qualifier.
> It ain't gonna happen. Every single developer will just go, "Oh,
> titleWord: that means a word in the title".
> > > I suggest an explain tag per index which records if it supports
> > > proximity or not. If it doesn't then a multi word search term
> > > would be treated as implicit AND as oposed to implicit PROX.
> > That just seems to me too complicated and too confusing.
> Here, at least, I agree! I strongly oppose this tendency to bundle
> more and more stuff into explain. If we learned one less from Explain
> Classic (we did, didn't we? _Please_ say we did! :-) it is surely
> that if it's too complicated, no-one will implement it. Let's not
> fall into that trap again.
If we have to write documents in the AA completely describing the
semantics of each index, then one, optional <setting> tag in an index
definition that can have about 6 or 7 other supports/default/setting tags
in it isn't going to break the camel's back.
is hardly complex, compared to having to define all of the attributes.
I'll drop it, if we can drop the requirement for the attributes second
level explain document, deal? :)
,'/:. Rob Sanderson ([log in to unmask])
,'--/::(@)::. 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