OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

search-ws message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [search-ws] application/sru+xml


It looks to me like you’ve dealt with <record> twice in that response. I’m hoping one of those was meant to be the <searchRetrieveResponse>.

 

I’m all in favor of adding the new xs:any element and deprecating the use of the various extraDatas, but I don’t want to go so far as to unnecessarily break any applications built on the use of extraData.

 

I think there’s extraData in Scan responses too.

 

I think this proposal is a nice compromise between my request for some well-know DC elements in the record and Mike’s insistence that the idea is foolish. I suspect I’ll just populate the <record> element with the appropriate atom elements and be done with it.

 

Ralph

 

From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
Sent: Wednesday, January 27, 2010 6:03 PM
To: OASIS SWS TC
Subject: [search-ws] application/sru+xml

 

I posted a message several days ago suggesting that we consider looking at possible changes to the default SRU 2.0 response, application/sru+xml, to allow arbitrary, foreign (namespaced), ignorable elements.   There was no discussion, does that mean nobody thinks it's a good idea or that nobody cares? 

 

As of right now the IETF draft ("00")  to register several mime types including SRU has expired and I am in the process of "negotiating" draft "01" (an unpleasant process, which you'll understand if you've ever negotiated with the IETF) and it seems to me that this is an opportune time to consider possible tweaks to this format. 

 

 

To begin, at the top level of the schema the elements are

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

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

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

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

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

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

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

<xs:element ref="extraResponseData" minOccurs="0" maxOccurs="unbounded"/>

<!—the above elements are carried over from SRU version 1.1; the following are new in version 2

<xs:element ref="resultCountPrecision" minOccurs="0" maxOccurs="unbounded"/>

<xs:element ref="facetedResults" minOccurs="0" maxOccurs="unbounded"/>

<xs:element ref="searchResultAnalysis" minOccurs="0" maxOccurs="unbounded>

 

 

I would like to think that we could keep the discussion bounded to the <records> element. That is, not try to wedge arbitrary elements elsewhere.

 

<records> is:

<xs:sequence>

<xs:element ref="recordSchema"/>

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

<xs:element ref="recordData"/>

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

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

</xs:sequence

 

My first suggestion is to get rid of the element <extraRecordData> and replace

 

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

with

 

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

 

 

Next,<record>is:

<xs:sequence>

<xs:element ref="recordSchema"/>

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

<xs:element ref="recordData"/>

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

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

</xs:sequence>

 

My next suggestion is to do the same thing with extraRecordData.

 

Please comment!

 

--Ray

 

 

 

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]