Unless we validate Ralph's premises (see related message) I would like to
suggest a middle ground on the prefixes:  I think it would be useful to have
one or more well-known prefixes (whether registered or otherwise published) and
leave room for discovering prefixes via explain. I suggest that there be a
convention for distinguishing well-known from private prefixes, to avoid
conflict (but nothing quite so elaborate as what we use for Z39.50 oids).
--Ray

Alan Kent wrote:

> Ray Denenberg [mailto:[log in to unmask]] wrote:
> >
> > How about if we register prefixes?  I'll be quite happy to do it if that
> > will help.
>
> LeVan,Ralph wrote:
> > No!  The Explain service will say waht prefix is expected!
> >
> > Ralph
>
> There are several different points of view in all this with different
> things trying to be achieved. This is what I *think* different people feel.
>
> * Some people want Explain to be the authoritive source of information
>   and a server defines whatever names for access points it supports.
>
> * Some people want to express a single query and be able to send it
>   to multiple servers. Explain cannot be easly used to solve this problem.
>
> I am in the latter camp, but don't mind the former if the latter
> can also be achieved. And I think both can be satisfied.
>
> My proposal I have tried to express is not to mandate names in CQL.
> So there is no CQL official registered list of prefixes. Instead,
> profiles can be developed independently to CQL which would typically
> define a set of names (which all shared a prefix). Servers conforming
> to this profile can then all accept queries conforming to the profile.
> But each server (via explain) describes exactly what it supports.
>
> If the above is acceptable, then (and only then) it *could* be decided
> in CQL to add support for the above by reserving a character in CQL
> to be used for prefixes (such as '.'). But there is no point arguing
> about this point unless the first proposal (or some variation) is
> accepted.
>
> So I am in favour of there being no requirement of a CQL implementation
> to implement anything to do with prefixes. So there is no CQL based
> registry as Ray offered.
>
> However, I am also in favour of *allowing* companion profiles to be defined
> which are shared by people who wish to use such profiles. In this case,
> Ray's offer to host such profiles I think would be a good idea.
> If CQL finally gets there, then CQL and whatever other profiles are
> developed can be put on the LoC or similar site, but as separate
> documents.
>
> I cannot see why there should be any objection to this approach
> (but am fully expecting someone to point out some deficency! :-).
> People who don't want prefixes and profiles as a part of CQL are
> satisfied (ie, use Explain to discover field names in database).
> People who want profiles are satisified (ie, can send a query
> without change to lots of servers - *if* those servers conform to
> the profile).
>
> Alan
>
> ps: I would almost prefer that attribute set definitions, such as
> Bib-1, STAS, etc, define the preferred short names to be used for
> those access points with the intent that they can be used in CCL
> or CQL or whatever. But I can imagine LOTS of arguing about which
> short acronym to use for what given all the Bib-1 variations on
> title, author, and subject!!! So I think Bath-like profiles might
> be a better place for such a thing.