Quoting Mike Taylor <[log in to unmask]>:
> What was the motivation for CQL change 7?
I hope reason and .. :-)
> Proximity. Defaults are now server defined, not standard
> defined. Hence "prox" can be anything the server wants to do
> proximately, not necessarily with a default of adjacency.
> I think I missed that discussion.
But you were there :-)
search prox//20 engine. For a text such as
<program>IB Engine 3.x</name>
Its a messy bit. Engine and Search are not in the same container in this
model. In another model, since we don't have an order explicitly in XML
(recall my mail a month or two back) we can't even talk about (in a
non "do it the way I want to" manner) the distance between (to use football
as in your taste)
How far is Arsenal from Tottenham Hotspur (beyond the distance between their
stadiums in town) when we have no warrants that the data is so marked up or
can (at this stage) call to document order or for that matter, define a
model transcendent of systems for a document order or even an encoding (we
can't and don't demand that its marked up as XML or ...)?
And adj? Is United (keeping even to document order) adjacent to Arsenal?
Should proximity be only restricted to a single contextual container or
envelope? Then we'd not have the idea of paragraph, sentence, line, chapter
etc. which are models to cover a document and transcend perhaps the markup.
Recall a line may contain one or more (or not even one) sentences. A sentence
may cover multiple lines.
I also wrote about the issue of "word". What's word metrics? In some systems
it can make sense but in many it can't. If we don't know that we're talking
about the same thing then we might as well just let people talk the why they
think is best and makes the most sense and hope that some form of communication
At this stage its best really to let the server make their own policies.
--- and in 2.0 my interest is to talk about the model of ancestor and
descendants of a match (hit) within a document (makes quite a lot of sense
in the OASIS context) to break away from our current fixed (pre-defined)
record model to a search directed model (recall my suggestion a few months
back). Again, I've already implemented this and so its not just dry
theory. I can show in praxis how this works.. and what kinds of problems
it "solves". Its the kind of functionality, I think, looking at the talk
of Xquery (which has shown itself to be terribly insufficient for drawing
up a model for "fulltext XML search") that could make SRU/W blow away the
rest of the "generic search protocol" playing field.
Edward C. Zimmermann, Basis Systeme netzwerk, Munich
Office Leo (R&D):
Leopoldstrasse 53-55, D-80802 Munich,
Federal Republic of Germany