The GILS Profile includes a GILS schema with a bunch of
named data elements (see http://www.gils.net/xml-en.xsd ).
Most GILS implementations allow searchers to search on
any GILS schema element, and I'd like to preserve that
potential in an SRW/CQL environment as well.

It is an easy matter to make CQL index names from GILS
schema elements by just converting the name to camel
case (getting back to to their ASN.1 names, BTW).

Trouble is, I already have elements in GILS with names like
"Record-Source". So, should the GILS Profile for CQL allow a
search on "gils.recordSource" or should it insist that the
CQL query can only use "rec.creationAgentName"?

Along the same lines, if one implements a Microsoft Office
search with CQL one will need to support the friendly MSO
property names such as DocTitle, DocSubject, DocAuthor,
DocEditTime, DocLastPrinted, DocPageCount, DocWordCount
(e.g.,
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/indexsrv/html/ixuwebqy_4drn.asp
).
We are NOT going to be successful with SRW if we insist
that everyone learn to use a mixed bag of index names:
dc.title, dc.subject, dc.author, mso.DocEditTime,
mso.DocLastPrinted, mso.DocPageCount, mso.DocWordCount
(and, I guess these last four would need to migrate
down to the Record context set?)

I don't quite see a full solution to all of this, but
I am wondering if it is really that important to have
each name prescribed in a separate context set. Maybe
CQL context sets should be the place where indexes live
IF AND ONLY IF they have an "unusual" definition. Any
index whose name conforms to the naming rules and is
composed solely of registered base concepts gets a free
ride (no context set prefix needed). Would that work?

Eliot