Rob,
The following is a possible use case for alwaysMatches.

In an OAI to SRW gateway to an authority file, one wants
to support the harvest of sets like the following:

  All records in the repository that contain
     -  personal name headings (MARC21 tag 100)
     -  corporate name headings (MARC21 tag 110)
     -  conference name headings (MARC21 tag 111)
     -  geographic name headings (MARC21 tag 151)

Larry

On Wed, 2 Mar 2005, Dr Robert Sanderson wrote:

> On Tue, 1 Mar 2005, Sebastian Hammer wrote:
> > At 09:48 PM 3/1/2005 +0000, Dr Robert Sanderson wrote:
>
> >>>> * matches zero or more characters.
> >>>> For any field, "*" will match anything, no matter your internal
> >>>> representation of the date.
>
> >>> Consider a server that does not support truncation at all. It _will_
> >>> have to do a special case in order to full this "new" requirement. But
> >>> it will reject all other terms with * in it. That's not elegant.
> >>
> >> As opposed to a relation modifier, which may or may not be supported, with
> >> special cases for the index, relation and value, which is somehow more
> >> elegant than a not-very-special case for a term only? I beg to differ :)
>
> > I think the kind of 'operator overload' which is implied in the use of
> > '*' is an inherently bad idea. Much better to be explicit about what it
> > is we want, and to get 'matches everything' on the table as a clear,
> > pronounced requirement which is visible in the language. Why? Because
> > CQL is already a complex language, and implementors are humans, and
> > humans are likely to make any mistake or take any dumb shortcut you
> > leave open to them in order to reach deadlines.  I think buggy
> > implementations of CQL are going to be one of the biggest threats to
> > interoperability (once we get our SOAP toolkits straightened out, or
> > drop SRW :-), and the easier and more clear we can make it, the better.
>
> If this were a critical piece of functionality, I would probably agree.
>
> But how many people have implemented the alwaysMatches attribute in
> Z39.50? Anyone? I know that we certainly haven't, and haven't had anyone
> ask us to.
>
> Where are the use cases for this?  While in theory it sounds nice to
> retrieve all records that have a title, is this actually a pointful
> distinction which is going to be actively used?  I don't think it will be,
> but I am certainly open to be convinced by real life experience and well
> defined use case scenarios.
>
> We could add a simple note in the cql context set saying that "*" matches
> everything (because everything is matched by 'zero or more characters')
> and hence a search for "*" will match all records that have the field.
>
> This seems much simpler and more likely to be implmented than a special
> case relation with a new relation modifier and a special case term.
>
> Rob
>
> PS.
>
> By your CQL comments, which I agree with, I take it that you're going to
> schedule an update to 1.1 for CQL-Java sometime shortly, right? ;)
> Especially as:
> 1) your proposal relies on a new relation modifier, which are CQL 1.1 (CQL
>     1.0 had them 'hard coded')
> 2) there are many other implementations which port from CQL-Java to other
>     languages.
>
>
>        ,'/:.          Dr Robert Sanderson ([log in to unmask])
>      ,'-/::::.        http://www.o-r-g.org/~azaroth/
>    ,'--/::(@)::.      Dept. of Computer Science, Room 805
> ,'---/::::::::::.    University of Liverpool
> ____/:::::::::::::.  L5R Shop: http://www.cardsnotwords.com/
> I L L U M I N A T I
>