Quoting Mike Taylor <[log in to unmask]>:

> I think you've missed an earlier part of the discussion.  CQL already
> has nice, general syntax for the general proximity searching.  What
> we're talking about here is whether a specific case of proxmity ("same
> element" searching) is best expressed using proximity with a specific

I don't sematically see "same element" (in the same leaf container)
as proximity.

Proximity is distance.. Within X characters.. Within X words.. within
some metric. Same element is NOT a metric.

Questions (that some people tend to, incorrectly I'd argue, associate with
proximity) like terms in the same paragraph, same line, same sentence etc.
are a result of content structure and not word metrics.

In the same element... What element?

We solved it in our own little "private" query space with the binary
operator "peer".

The RPN query: "search" "retrieval" PEER
meaning that the terms "search" and "retrival" are in the same (any) leaf.

We, of course, have want to ask for terms in a specific element (named, and
not just the final leaves). We addressed this in our private language with
a binary operator as pair Operator:Fieldpath, for example
   AND:RSS\CHANNEL\DESCRIPTION
and in any "Description", not just those under channel under .. 
   AND:DESCRIPTION

same paragraph, line etc. are given content structure child's play..

The trick we have is to then map whatever query language for an interface
we want into our private language.


> set of parameters, and if so whether it merits an alias such as "with"
> or "where".  For this, "near" would be totally inappropriate.



-- 
-- 
Edward C. Zimmermann, Basis Systeme netzwerk, Munich
Office Leo (R&D):
   Leopoldstrasse 53-55, D-80802 Munich,
   Federal Republic of Germany
Telephone:   Voice:=  +49 (89) 385-47074  Corp.Fax:= +49 (89)  692-8150
 Nomadic (SMS/MMS/Fax):= +49 (176) 100-360-55  Alt.Mobile:= +49 (179) 205-0539
http://www.nonmonotonic.net