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

[Matthew Dovey <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.

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