[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [search-ws] SRU Diagnostics: Annex C
All good arguments to abandon info URIs entirely and switch to URLs. {oasisBaseURL}/cql/diagnostic/10-49 {oasisBaseURL}/sru/diagnostic/general/1-9 {oasisBaseURL}/sru/diagnostic/resultSet/50-60 Ralph -----Original Message----- From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov] Sent: Tuesday, December 28, 2010 12:02 PM To: search-ws@lists.oasis-open.org Subject: RE: [search-ws] SRU Diagnostics: Annex C 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 --------------------------------------------------------------------- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]