[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [search-ws] SRU Diagnostics: Annex C
> From: Matthew Dovey [mailto:m.dovey@jisc.ac.uk] > In SRU 1.0/1.1 if my memory serves, we used URIs for diagnostic codes > rather than numeric values. That's still the case. Note the prose at the top of the diagnostic annex (C): "The diagnostics below are defined for use with the following SRU diagnostic namespace: info:srw/diagnostic/1. The number in the first column identifies the specific diagnostic within that namespace (e.g., diagnostic 2 below is identified by the URI: info:srw/diagnostic/1/2)." --Ray > > This had the advantage that in the SRU doc we defined a namespace for > SRU errors, and defined the values in that namespace, and didn't have > to reserve any ranges for other purposes. > > The CQL document could define a new namespace for CQL errors in the CQL > document, and define its values there. > > And it was easy for third parties, alternative query languages, > extensions etc. to define their own error codes by defining their own > namespace accordingly. > > Etc. > > Can someone remind me why we went back to just numeric values (and > hence the issue of needing to pre-reserve ranges in the SRU doc)? > > Matthew > > > > -----Original Message----- > From: LeVan,Ralph [mailto:levan@oclc.org] > Sent: 08 December 2010 05:43 > To: Ray Denenberg, Library of Congress; Hammond,Tony; search- > ws@lists.oasis-open.org > Subject: RE: [search-ws] SRU Diagnostics: Annex C > > I think that's the right decision. > > > > I think it's a little peculiar too, but I think Tony is right in saying > that a CQL error in SRU is and SRU error. We have no idea whether one > of our CQL diagnostics could be returned sensibly in some other > environment where CQL (theoretically) be used. That theoretical > framework would need to have its own CQL diagnostics. > > > > Ralph > > > > From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov] > Sent: Friday, December 03, 2010 12:51 PM > To: Hammond,Tony; search-ws@lists.oasis-open.org > Subject: RE: [search-ws] SRU Diagnostics: Annex C > > > > In the interest of moving forward, quickly, I'm going to consolidate > all diagnostics into a single annex and it will go into SRU, and there > will be no diagnostic lists in any of the other specifications. The > other specs can point to the SRU annex. > > > > I realized while looking at Scan yesterday that there are diagnostics > that scan would use that would also be used by SRU ("invalid > stylesheet" for example) and we really don't want to duplicate the same > diagnostic across multiple specs. > > > > --Ray > > > > From: Hammond, Tony [mailto:t.hammond@nature.com] > Sent: Tuesday, November 30, 2010 3:16 AM > To: Denenberg, Ray; search-ws@lists.oasis-open.org > Subject: RE: [search-ws] SRU Diagnostics: Annex C > > > > > > > "too many boolean operators". Would you consider this more an SRU > diagnostic or a CQL diagnostic? > > I would regard that as an SRU diagnostic about a query (CQL) condition. > It is the SRU server that dispenses these exceptions. Whatever query > parsers are used by the SRU server they have no voice back to the > client. It is SRU that does all the talking. > > If we added an XYZ query parser it could equally use the 10-49 > diagnostics block. There is nothing CQL specific about them. > > Tony > > > -----Original Message----- > From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov] > Sent: Mon 11/29/2010 6:50 PM > To: Hammond, Tony; search-ws@lists.oasis-open.org > Subject: RE: [search-ws] SRU Diagnostics: Annex C > > "*all* the diagnostics are *SRU* diagnostics" > > > > I don't see it that way. Then SRU would be taking responsibility for > listing diagnostics for every query language that might be used with it > -- as well as other protocols that might be used in conjunction, e.g. > Scan. > > > > "too many boolean operators". Would you consider this more an SRU > diagnostic or a CQL diagnostic? > > > > --Ray > > > > > > From: Hammond, Tony [mailto:t.hammond@nature.com] > Sent: Monday, November 29, 2010 11:52 AM > To: Denenberg, Ray; search-ws@lists.oasis-open.org > Subject: RE: [search-ws] SRU Diagnostics: Annex C > > > > Hi Ray: > > I think this is missing the point a little: *all* the diagnostics are > *SRU* diagnostics, although some are generated on account of a CQL > condition which is detected by the *SRU server*. It is the SRU server > that is sending the diagnostics not any CQL parser. > > Hope that clarifies where I'm coming from. > > Tony > > > -----Original Message----- > From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov] > Sent: Mon 11/29/2010 4:19 PM > To: Hammond, Tony; search-ws@lists.oasis-open.org > Subject: RE: [search-ws] SRU Diagnostics: Annex C > > Well the problem as I see it is this. I don't think it would be proper > to > include cql diagnostics in a normative part of the sru spec. > Currently, > the list of diagnostics is normative. We could change that to non- > normative. Or we could list normative and non-normative diagnostics > separately - in normative and non-normative sections respectively (of > course, cql diagnostics would be normative within the cql spec). > > What do you suggest? I am somewhat reluctant to make first class sru > diagnostics non-normative. But only somewhat. > > > > --Ray > > > > From: Hammond, Tony [mailto:t.hammond@nature.com] > Sent: Monday, November 29, 2010 11:05 AM > To: Denenberg, Ray; search-ws@lists.oasis-open.org > Subject: RE: [search-ws] SRU Diagnostics: Annex C > > > > >From a developer point of view I don't think this is very helpful. We > >need > a > consolidated set of diagnostic responses which is generataed by and > received from the *SRU* application. > > To repeat the CQL-subset in the CQL document would be a handy reference > but we should not allow the definitive list to be fragmented. > > Is my 2 cents. > > Tony > > > > -----Original Message----- > From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov] > Sent: Mon 11/29/2010 3:13 PM > To: Hammond, Tony; search-ws@lists.oasis-open.org > Subject: RE: [search-ws] SRU Diagnostics: Annex C > > Here is what I think we should do (and I think we discussed this a > while back and decided to do this): > > change in SRU "Diagnostics 10-49 reserved for CQL" simply to > "Diagnostics 10-49 reserved" . And in CQL add an annex that lists CQL > diagnostics. > > > > --Ray > > > > From: Hammond, Tony [mailto:t.hammond@nature.com] > Sent: Monday, November 29, 2010 7:32 AM > To: search-ws@lists.oasis-open.org > Subject: [search-ws] SRU Diagnostics: Annex C > > > > Hi: > > We have a normative Annex C in SRU 2.0 draft which says this: > > "Diagnostics 10-49 reserved for CQL" > > Doesn't help me much. I had to root around in Java code till I found > the list I needed. (And yes, I should have gotten this from the SRU > diagnostics registry. Some reason I thought I had looked there - but > obviously hadn't.) > > So, I guess we should have a *complete* listing of *all* SRU diagnostic > codes in the SRU draft itself. (The annex is normative, after all.) And > I wonder if we shouldn't also include unassigned numbers within the > sequence, e.g. #9, #75-79, etc., for general accountability. > > :) > > Cheers, > > Tony > > > *********************************************************************** > ***** > **** > DISCLAIMER: This e-mail is confidential and should not be used by > anyone who is not the original intended recipient. If you have received > this e-mail in error please inform the sender and delete it from your > mailbox or any other storage mechanism. Neither Macmillan Publishers > Limited nor any of its agents accept liability for any statements made > which are clearly the sender's own and not expressly made on behalf of > Macmillan Publishers Limited or one of its agents. > Please note that neither Macmillan Publishers Limited nor any of its > agents accept any responsibility for viruses that may be contained in > this e-mail or its attachments and it is your responsibility to scan > the e-mail and attachments (if any). No contracts may be concluded on > behalf of Macmillan Publishers Limited or its agents by means of e-mail > communication. Macmillan > > Publishers Limited Registered in England and Wales with registered > number > 785998 > Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS > *********************************************************************** > ***** > **** > > > > > ________________________________ > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1170 / Virus Database: 426/3312 - Release Date: 12/12/10 > > > --------------------------------------------------------------------- > 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]