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

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

Sorry Matthew, didn't read your entire message the first time.

Here is how I recall what we decided about this originally, with 1.0/1.1.
We would define a single diagnostic namespace for SRU, for the maintenance
agency, and anyone else could define their own namespace. Within the
maintenance agency namespace there would be diagnostics of every category,
and while we did allocate ranges for different categories, we agreed that if
we ran out of space within a category then we would just allocate another
category somewhere else within the space. 

We''ve never discussed that within the OASIS group but I'm sure that's the
same idea.

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?

--Ray 

> -----Original Message-----
> From: Matthew Dovey [mailto:m.dovey@jisc.ac.uk]
> Sent: Monday, December 13, 2010 7:27 AM
> To: LeVan,Ralph; Denenberg, Ray; Hammond,Tony; search-ws@lists.oasis-
> open.org
> Subject: RE: [search-ws] SRU Diagnostics: Annex C
> 
> In SRU 1.0/1.1 if my memory serves, we used URIs for diagnostic codes
> rather than numeric values.
> 
> 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