Draft message to SRU implementors group

Draft message. Please comment.

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------

At last week's teleconference of the OASIS Web Services TC, we agreed to the following strategy: We will develop a base, or core, specification - an abstract model from which serializations/profiles/bindings/extensions/specializations will be developed.

We haven't yet decided on terminology: base specification, core specification, or abstract model; serialization, profile, binding, extension, or specialization. (For the latter set, several of these terms may be used with different meaning.) Temporarily we will use "core specification", and use "profile" and "binding" interchangeably.

The core specification will leave open nearly all possible choices. For example, parameters will be defined but not characterized as mandatory/optional/repeatable. In some cases a parameter may be defined though its name might not be specified (for example, the query parameter). A profile may then specify that a given parameter may be mandatory or optional, repeatable or not-repeatable, must not occur, etc.

This effectively renders moot some of the discussion we have been having, at least as far as the core specification is concerned. The core specification will not prescribe a concrete response format, so the issue of which response format will be mandatory, and the issues surrounding ATOM, do not apply to the core specification. Of course it doesn't mean the issues go away, they just get pushed down a level. However, different communities can make different decisions - one profile might ignore ATOM altogether while another might make it the sole response format. Query type issues also become moot at the core specification level. Different profiles will specify different query types.

So, two products implementing the core specification may or may not interoperate. Their chances increase if they both implement a common profile, and increase further if they both implement a common specialization of that profile, and so on. And of course two products implementing different profiles might not interoperate at all, but it may be that they are not meant to interoperate, their applications are different. In any case the level of interoperability is ultimately decided by business needs. If profile A calls out the SRU response format and profile B calls out ATOM, there is nothing to stop an implementor from supporting profile A and profile B in a product.

Some profiles will be developed within OASIS as part of this committees work, others within OASIS outside this committee, and some in other standards groups or communities. The number of profiles to be developed is difficult to estimate at this point, but there will be at least three to start with: SRU 1.2, OpenSearch, and SRU 2.0.

SRU 1.2
The next order of work for the Committee will be to draft the core speccification and the SRU 1.2 binding. This will serve as proof of concept. So the SRU 1.2 binding will be done within the committee.

OpenSearch
This will also be done within the Committee. We will enlist OpenSearch experts to work with us on this. It may be that the OpenSearch specification itself will be formalized as an RFC within IETF. That would occur independent of OASIS, and our work would be to write a profile which would simply be a binding to the RFC. Before the RFC work is done we might write a temporary binding to the existing OpenSearch specification.

SRU 2.0
The original idea behind this OASIS committee was to work on the difficult problems of SRU (proximity, for example) and the resulting standard would be a major revision of SRU (in contrast to a minor revision, for example, moving from 1.1 to 1.2 where the changes were minor, did not require a formal process, and was done within the SRU implementor group), i.e. SRU 2.0. It was also originally envisioned that SRU 2.0 would incorporate OpenSearch. Although this is a different direction, there is still a need to develop SRU 2.0 - separate from OpenSearch, but under a common framework.

Where the work on SRU 2.0 will be done is an interesting (and open) question and there will probably be much discussion. Wherever it is done, within OASIS, within a different standards group (NISO, for example) or simply within the SRU implementor group: (1) if not done as part of this committee's work, the Committee nevertheless needs to stay close to the effort to be sure that we don't end up with a result that is not compatible with the core specification; and (2) if not done within the the SRU implementors group, that group nevertheless need to participate actively in the development.

Probably there will be very little or no new technical discussion initiated by the Committee on this list for a period while we sort out these questions, and develop a draft of the core specification and binding to SRU 1.2. When these documents are drafted they will be submitted for review.

search-ws message