I have only one question:

Why on earth would one prefer to define an "element" as a "thing which contains other things", and "container" as a "thing which contains no other things" when this is *exactly* the reverse of their normal English usage? Is there a perverse desire here to make things (pun intended) as confusing as possible?

Peter Noerr

> -----Original Message-----
> From: SRU (Search and Retrieve Via URL) Implementors [mailto:[log in to unmask]] On Behalf Of Edward
> C. Zimmermann
> Sent: Saturday, July 03, 2010 4:07 PM
> To: [log in to unmask]
> Subject: Re: CQL example for prox/unit=
> 
> Ray, I'm actually quite pleased. I feel almost as if someone has been
> listening! There are, however, just a few points still that need to be voiced..
> 
> 
> On Sat, 3 Jul 2010 15:40:52 +0100, Mike Taylor wrote
> > Surely "container" here means EXACTLY the same thing as "element",
> > i.e. whatever you want it to mean?
> >
> 
> In SGML containers are called elements. When we want to distinguish between an
> element and the containers it contains we can talk about container thus they
> are, in semantic use, not always the same. See below.. (my argument is that
> they have things backwards).
> 
> 
> On Fri, 2 Jul 2010 17:55:02 -0400, Ray Denenberg wrote
> > Peter, that's an example of structured proximity searching and that
> > has been abandoned in the OASIS CQL spec, the most recent draft of
> > which is at http://www.loc.gov/standards/sru/oasis/current/cql.doc
> >  which I recommend that you look at, because it  clarifies (and
> > simplifies) proximity.
> 
> On Sat, 3 Jul 2010 09:31:40 -0400, Ray Denenberg wrote
> > Just want to add this.  The problem isn't so much in saying "find A
> > and B in the same element", the problem is when the distance is
> > greater than zero as in "find A and B separated by two elements".
> >  In the OASIS spec, the notion of element is discarded and the more
> > abstract notion of "container" is defined, and you can "find A and B
> 
> I would argue that the predicate "container" should be used as a name for a
> specific kind of element, namely atomic containers, viz. containers with no
> sub-containers (indexes). An element here would be a container when it has no
> sub-elements. In a typical flat format such as common to Z applications the
> fields are elements and containers..
> 
> > in the same container"  (with no notion of finding A and B separated
> > by, say, two containers).  --Ray
> 
> Correct. Since in XML and many other models there is no order one can't talk
> about distance. The only distance one can talk about is bytes according to how
> the information was marked-up but only if the information was marked-up.
> 
> The doc: "A container is a structure containing one or more indexes.  For
> example the server may support a container whose name is ‘author’ that
> contains indexes ‘name’ and ‘date’.  In that case the server would support a
> query  (see example) to find  an author with a specific name and date.  (This
> is contrasted with a Boolean query which may return undesired results because
> they have multiple authors, some of which have the desired name but the wrong
> date and others the specified date but the wrong name.) The server should list
> supported containers in its Explain file, and for each container, the indexes
> that it contains."
> 
> Exactly. One has here named sub-paths   author/name  and author/date but also
> the anonymous path "in the same container". I, however, would swap around the
> semantics and view "container" as the lowest node and element any .. example:
> 
> <book>
>  <title>Re: CQL example for prox/unit=</title>
>   <author>
>     <name>Edward C. Zimmermann</name>
>     <date>11 Feb 2000</date>
>    </author>
>   <edition>2nd</edition>
>   <date>3 July 2010</date>
> </book>
> 
> The element book contains title, author, edition, date etc.
> In the "same container" would however mean exclusively the lowest node (leaf).
> Containers should have no sub-elements
>   Edward and Zimmermann are in the same container (book/author/name>)
>   Edward and CQL are not in the same container even if, per your semantics the
> container author as two sub-elements.. whence the same container would be the
> same "author" container.
> 
> In my IB engine the semantics for "in the same container" only applies to the
> lowest.. e.g. bookauthor/name instance or book/author/date instance..
> If I want to search for Edward and SQL in the same book then I search for
> it by name WITHIN:book  or explicitly in path WITHIN:\book  (I use \ for / as
> / is used to denote fields). That is: elements (and paths).
> 
> In my above example:   2000, Zimmermann are in the same author.. they are also
> within the same book..  CQL and Zimmermann are within the same book but not
> within the same author. etc...  2010 and July are in the same date. July and
> 2000 are not in the same date but are in the same book.. etc.
> 
> http://www.ibu.de/RelationalHierarchicalIR
> http://www.ibu.de/IB_Query_Fields
> 
> --
> 
> Edward C. Zimmermann, NONMONOTONIC LAB
> Basis Systeme netzwerk, Munich Ges. des buergerl. Rechts
> http://www.nonmonotonic.net
> Umsatz-St-ID: DE130492967