[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]