RE: [search-ws] SRU Diagnostics: Annex C

["Ray Denenberg, Library of Congress" <rden@loc.gov>]

While I'm working on a new draft we might as well resolve this issue that
Matthew has brought up. Does anyone besides Matthew and me have an opinion
on this?

The current method to identify a standard diagnostic is via an info URI, the
base URI being 

info:srw/diagnostic/1

where the '1', called the "authorith component", is assigned to "SRU".  And
then the actual diagnostic is appended, so for diagnostic 2 the URI would be


info:srw/diagnostic/1/2.

The problem Matthew cites it that we have allocated ranges for different
classes of diagnostics, so 1-9 for general, 10-49 for cql, 50-60 for result
sets and so on.   So if you have another cql diagnostic it cannot be 51,
instead you have to start a new range in an unallocated area.  Which may be
somewhat akward but which I don't see as a real problem.   Matthew suggests
that we could instead use different "authority components" and then all
numbering could start with 1. 

Two problems I have with this. 

1.  It would make interoperability more difficult with earlier versions. 
2.  That component of the URI is the "authority component" intended to be
assigned to an authority who intends to assign diagnostics. In fact,
authorith strings 1-15 have already been assigned. I'm not sure how we would
go about implementing this suggestion, start assigning categories with 16,
where that component has an entirely different meaning?  Start all over with
a new URI?  

Any opinions?

--Ray





> -----Original Message-----
> From: Matthew Dovey [mailto:m.dovey@jisc.ac.uk]
> Sent: Monday, December 13, 2010 3:30 PM
> To: Denenberg, Ray; 'LeVan,Ralph'; 'Hammond,Tony'; search-
> ws@lists.oasis-open.org
> Subject: RE: [search-ws] SRU Diagnostics: Annex C
> 
> > The idea of instead defining different namespaces for different
> > categories of diagnostics is an interesting alternative approach, but
> it would make interoperability more difficult with earlier versions,
> wouldn't it?
> 
> I don't see why this should be an issue any more than the other changes
> to SRU 2.0 that hinder backwards interoperability such as the changes
> to the schema namespaces.
> 
> There is no particularly reason why the numbers in a particular
> namespace have to be contiguous or start at one, so the cql diagnostics
> could have the same codes just in a different namespace.
> 
> Matthew
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php