# Presentation: 362647

## SRU Standardization

- Ray Denenberg
- Library of Congress

- What to standardize
- What standards body

## What to Standardize: Candidates

- SRU
- SRW
- ZeeRex
- CQL
- SRUP
- Scan
- Update

## At Minimum ....

- SRU
- CQL

## Leif Andresen, danZIG ....

- very important to keep the connection to W3C and the SOAP standard. SOAP web service is defined as the Danish e-government basic web service standard - so we need SRW.
- A standard method to describe the service of a server like Explain and a service to order a list of words *[presumably Scan]* are still of great value.

## Add:

- SRW
- ZeeRex
- Scan

## So.....

- SRU
- CQL
- SRW
- ZeeRex
- Scan

## Leaving ....

- SRUP
- Update

## Rob  (on SRW) ....

- I'm in favour of leaving it in, to be taken out if that's the consensus if the standardisation process.
- There'll be enough religious wars between OpenSearch and SRU without adding SOAP vs REST.

## SRW?

- by including SRW, we avoid  the religious war - The rest vs. web services debate – If we have them both covered we can't be accused of favoritism.
- On the other hand adding a SOAP-basedweb-service, not just a REST-like URL, would enormously increase the scope of what we're doing and likely attract a lot of people towards the group who would maybe not care about being involved in a URL-only effort.

## Matthew ....

- The way I've approached it (and this is inherent in the WSDL) is that there is a standard protocol description and then alternative bindings (or application profiles)  in the same way that BER over TCP/IP was an  application profile of the Z39.50 protocol description.

## What body?

- NISO
- ISO
- IETF
- W3C
- OASIS
-  others?

**The Winner!**

- Standards thought to be “for the library community”, do not get attention outside the library community, and do not get implemented by major vendors, because of the small market (whether perceived or real). Wherever possible and practical, standards developed for our community should be relevant to the world at large.

- Conversely, standards that are developed for the world at large need to accommodate library needs. Library community participation in mainstream standards bodies is an essential part of this process.

- OASIS is often used as a neutral ground for merging competing de facto standards into an industry standard. It uses a lightweight, open process expressly designed to promote industry consensus and unite disparate efforts.

## Mike Taylor

- the world clearly needs a (single,) well-defined, powerful protocol for searching by URL with results returned in XML

- There are competing protocols in development, one of which will drive this standardization effort if SRU does not, and it likely would not meet the needs of the library, publishing, and information retrieval communities.

## Bernd Simon (SQI)

- As far as I can speak for the SQI folks an Oasis initiative would be much appreciated and we would be ready to contribute. I would not find it difficult to accept an altered version of an SQI specification as an Oasis standard, since mapping between different interface is not really a big deal and an Oasis standard would certainly boost industry adoption.

## OASIS Cycle

- Start an open list to sort out the charter  - determine:
-  if other parties (A9 etc.) would participate
-  the level of change input from other parties might introduce
- Estimate  how long it would take to get to a committee draft.

## OASIS Cycle

- Committee Draft
- Charter specifies, e.g., to deliver a committee draft within 6 months. (The version prior to public comment and a vote of all OASIS members.)
- Committee draft to standard
- Typically 3 months - Committee draft open to 60 day Any resulting substantive changes, then a further review public review cycle (15 days). Then spec goes to OASIS members who have 15 days to read the spec, and a further 15 days to vote.

## Approaches	

- formalize the changes we have now,  call the result SRU 1.2;
- take all the more complex problems into the standardization process with the goal ofgetting them fixed in (the standard) SRU 2.0?

## Matthew .....

- any standardization route may introduce changes especially if the reason to standardize in the first place is to raise awareness and usage within new (and larger) communities. Such new/larger communities will almost certainly have new scenarios which may need to be accomodated into the specification.

- Starting the process now with items on the table for a new version (and hence some flexibility) seems more sensible than waiting until version  1.2 is to some degree set in stone.
- Also if the reason for doing this it to gain acceptance within new communities, it will be much more successful if such new communities feel that they had some say in its development, and hence feel that they have a stake in its success than foisting a ready made/fixed in stonestandard upon them.