Re: DEFECT in SearchRetrieve (FW: Question about searchRetrieve 1.0 'recordIdentifier' element)

[Chet Ensign <chet.ensign@oasis-open.org>]

Hi Ray, 

This could be handled with an Errata document. It will be pretty simple to do especially since the issue is in the schema, not the documentation. Here is how I would handle it... 

- Draft an Errata document as a CSD that explains the element was missing from the specification. We can provide a template and decide exactly how to write  up the errata 

- Package the Errata document and the fixed schema and put them out for public review 

- After public review, the TC votes to approve it as an Approved Errata 

- We publish the OS with Approved Errata and it becomes the current version of the Standard 

/chet

On Thu, Jun 27, 2013 at 10:30 AM, Ray Denenberg <rden@loc.gov> wrote:

I believe there is a defect (minor) in the sruResponse.xsd  schema.

 

Note in:

http://docs.oasis-open.org/search-ws/searchRetrieve/v1.0/os/part3-sru2.0/searchRetrieve-v1.0-os-part3-sru2.0.html#_Toc324162490

 

The element <recordIdentifier> is defined.  It is omitted in the schema and should have been included. See below.

 

 

Please let me know if you agree with my assessment that this is a defect.

 

Chet - what is the procedure for fixing this?

 

--Ray

 

From sru2.0.html: 

Each <record> element is structured into the elements shown in the following table.

Table 3: Structure of the <Record> Element

Element	Type	Occurence	Description
<recordSchema>	xs:string	mandatory	The URI identifier of the XML schema in which the record is encoded. Although the request may use the server's assigned short name, the response must always use the full URI.
<recordXMLEscaping>	xs:string	mandatory	'string' or 'xml'.
<recordData>	<stringOrXmlFragment>	mandatory	The actual  record.
<recordIdentifier>	xs:string	optional	An identifier for the record by which it can unambiguously be retrieved in a subsequent operation. For example via the 'rec.identifier' index in CQL.
<recordPosition>	xs:positiveInteger	optional	The position of the record within the result set.
<extraRecordData>	<xmlFragment>	optional	Any additional information to be transferred with the record.

 

 

From the Schema (note omission of recordIdentifier):

 

 

<!-- recordDefinition-->

<xs:complexType name="recordDefinition">

            <xs:sequence>

                        <xs:element ref="recordSchema"/>

                        <xs:element ref="recordPacking" minOccurs="0"/>

                        <!--

        recordPacking has different meaning when used for versions 1.2 or earlier than for 2.0 or later.

             -->

                        <xs:element ref="recordXMLEscaping" minOccurs="0"/>

                        <!--

                                                recordXMLEscaping  valid only for 2.0 or later.

  -->

                        <xs:element ref="recordData"/>

                        <xs:element ref="recordPosition" minOccurs="0"/>

                        <xs:element ref="extraRecordData" minOccurs="0"/>

                        <xs:any minOccurs="0" maxOccurs="unbounded" namespace="##other" processContents="lax"/>

            </xs:sequence>

</xs:complexType>

 

 

 

-----Original Message-----
From: Ray Denenberg [mailto:rden@loc.gov]
Sent: Thursday, June 27, 2013 10:17 AM
To: 'Jörg Prante'; Denenberg, Ray
Cc: 'Bernhard Assmann'
Subject: RE: Question about searchRetrieve 1.0 'recordIdentifier' element

 

Hi Jörg - recordIdentifier was intended to be included in the schema (within recordDefinition).  Its omission is a defect.   Thanks for catching this.

 

As this is the first defect reported I will need to investigate the process to get it fixed.

 

I'll get back to you, thanks again.

 

Ray

 

> -----Original Message-----

> From: Jörg Prante [mailto:prante@hbz-nrw.de]

> Sent: Wednesday, June 19, 2013 9:42 AM

> To: Denenberg, Ray

> Cc: Bernhard Assmann

> Subject: Question about searchRetrieve 1.0 'recordIdentifier' element

>

> Hi,

>

> I'd like to know whether it is allowed to use a "recordIdentifier"

> element in searchRetrieve 1.0 or not.

>

> In the XML schema at

>

> http://docs.oasis-open.org/search-

> ws/searchRetrieve/v1.0/os/schemas/sruResponse.xsd

>

> it is missing. So, when generating valid SRU 2.0 responses, I am

> forced to drop the "recordIdentifier" element.

>

> But, in the specification at

>

> http://docs.oasis-open.org/search-ws/searchRetrieve/v1.0/os/part3-

> sru2.0/searchRetrieve-v1.0-os-part3-sru2.0.html#_Toc324162490

>

> it is listed as optional, and it seems it is allowed for use in SRU

> 2.0 responses.

>

> Do I miss something? I can't figure out what is correct.

>

> Thanks in advance for your help.

>

> Best regards,

>

> Jörg

>

>

>

> --

> Jörg Prante

> hbz, Gruppe Portale

> - Digitale Bibliothek und Online-Fernleihe - Postfach 270451, 50510

> Köln, Deutschland Telefon +49-221-40075-156, Fax +49-221-40075-190

> prante@hbz-nrw.de http://www.hbz-nrw.de

 

--

/chet 
----------------
Chet Ensign
Director of Standards Development and TC Administration 
OASIS: Advancing open standards for the information society
http://www.oasis-open.org

Primary: +1 973-996-2298
Mobile: +1 201-341-1393 

Check your work using the Support Request Submission Checklist at http://www.oasis-open.org/committees/download.php/47248/tc-admin-submission-checklist.html 

TC Administration information and support is available at http://www.oasis-open.org/resources/tcadmin

Follow OASIS on:
LinkedIn:    http://linkd.in/OASISopen
Twitter:        http://twitter.com/OASISopen
Facebook:  http://facebook.com/oasis.open