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

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

Not going to work.

First of all
> So, info:cql/diagnostic/1/10-49 for the current CQL diagnostics,

Can't do that.  The part of the info: URI immediately following info:,
called the "info: namespace" we do not have the authority to stick "cql"
there. Only the "info:" people can assign that, And (1) it's a painful
process, and (2) I have heard that they are no longer assigning info:
namespaces.   I do own the "srw" info: namespace, so we could do
info:srw:cql....

Second,
>Info:sru/diagnostic/1/1-9 for SRU general
> diagnostics, info:sru/diagnostic/2/50-60 for result set diagnostics,

(It's info: srw not sru, but that's a small point)  The point of my first
message was that the '1' and '2' are authority components already assigned.
We cannot just repurpose them as namespace components. 

--Ray




> -----Original Message-----
> From: LeVan,Ralph [mailto:levan@oclc.org]
> Sent: Tuesday, December 28, 2010 11:40 AM
> To: search-ws@lists.oasis-open.org
> Subject: RE: [search-ws] SRU Diagnostics: Annex C
> 
> I'd propose a different URI for cql and a different authority component
> for each range of SRU specific diagnostics.  I'd assign the same
> numbers as are currently being used to each of the new authority
> components.
> That might make for gaps before and after the ranges, but I don't see
> that as a big deal
> 
> So, info:cql/diagnostic/1/10-49 for the current CQL diagnostics, with
> unlimited room for growth.  Info:sru/diagnostic/1/1-9 for SRU general
> diagnostics, info:sru/diagnostic/2/50-60 for result set diagnostics,
> etc.
> 
> Ralph
> 
> -----Original Message-----
> From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
> Sent: Tuesday, December 28, 2010 11:12 AM
> To: search-ws@lists.oasis-open.org
> Subject: RE: [search-ws] SRU Diagnostics: Annex C
> 
> 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
> 
> 
> ---------------------------------------------------------------------
> 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
> 
> 
> 
> 
> ---------------------------------------------------------------------
> 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