Proposal
for a Z39.50 Present Request parameter:
compSpec-2

For discussion at the April 2002 ZIG meeting.

Background
Z39.50-1995 has a rich, well-developed retrieval facility, based on abstract concepts that many people feel are sound and still relevant, and in fact validated in a web context (GRS-1 was a precursor to XML; Z39.50 tagSets have been formalized as namespaces and Z39.50 schemas as XML schemas.)

However the retrieval facility has not been widely implemented; there are a number of reasons suggested for this. One theory is that these concepts were too far ahead of their time, consequently were not implemented during the first few years after standardization, and instead work-arounds were developed which continue to be employed. Another suggestion is that even though the abstractions are sound, they were engineered into the protocol in a manner that is not easy to implement.

Finally, some of the features perhaps are, in retrospect, more complicated than necessary; that is, their complexity isn't justified by the functionality they provide versus alternative simple approaches. A case in point is element specification versus element sets. Profile developers find it simpler to define a handful of element set names than to prescribe element specification. And since element specification requires the use of compSpec and version 3, by avoiding element specification, so long as a profile does not specify other features that require these, it can avoid requiring compspec and version 3. This line of reasoning has led to many implementations that do not support version 3 or compspec.

While the decision to presrcibe element set names rather than element specification is often sound, by avoiding the use of copmSpec and version 3, some useful capabilities are precluded, for example the ability to specify a schema and character encoding. And while there has not been extensive buy-in of GRS-1, the concepts of Schemas, tagSets, variants, and element specification were developed with GRS-1 in mind. But people want to be able to specify a schema with an XML record, or a character encoding with a MARC record.

And in fact many application simply don't need all the complex capabilities provided by compSpec, for example:

• Element specification, variant, tagSet.
• "selectAlternative syntax".
• ability to provide specification per database, not just globally per request.
• record syntax (That is, the ability to specify it within compSpec, when it is already a parameter of the Present request itself.)

This paper seeks to motivate exploration of ways that desired capabilities might be incrementally re-engineered into the protocol. The proposal below suggests a way to incorporate a few retrieval capabilities without requiring buy-in to the full retrieval facility.

Proposal
The suggestion is to add a new parameter to the Present request: compSpec-2. It would incorporate a simple list of parameters (to be determined). In particular it would include Schema and CharacterEncoding. It would not however be burdened with the complexities listed above. (An option bit would be defined corresponding to this parameter, which, when negotiated would preclude the use of the existing compSpec parameter.)