Re: [search-ws] Re: description language

["Larry E. Dixson" <ldix@loc.gov>]

Ray,
I have some basic questions that we must have covered very early
in our discussions.  Why are we not attempting to use NISO
Z39.92 to describe arbitrary and SRU compliant servers?

Did we, instead, want to have our search-ws descriptions
more like the Open Search description?

http://www.opensearch.org/Specifications/OpenSearch/1.1#OpenSearch_description_document

If that is the case, why is that a better approach?

Sorry, but I think I need to understand these points before
I can go further into this discussion. 

Thanks.
Larry

On Mon, 21 Apr 2008, Ray Denenberg, Library of Congress wrote:

> This discussion is moving very slowly, in fact not at all. The
> following is for purposes of moving it along.
> 
> Please look at the following XML fragment, an example of how a
> server could provide a description of its search response,
> corresponding to SRU 1.2:
> 
> -----------------------------------------------------------------------
> <response>
> <abstractElements>
> <!-- -->
> <element>
> <abstractName>version</abstractName>
> <actualName> version</actualName>
> <occurrence>1</occurrence>
> <xpath>/version</xpath>
> <value>"1.2"</value>
> </element>
> <!-- -->
> <element>
> <abstractName>numberOfItems</abstractName>
> <actualName> numberOfRecords</actualName>
> <occurrence>1</occurrence>
> <xpath>/numberOfRecords</xpath>
> <value>positiveInteger</value>
> </element>
> <!-- -->
> <element>
> <abstractName>resultSetId</abstractName>
> <actualName> resultSetId</actualName>
> <occurrence>0-1</occurrence>
> <xpath>/resultSetId</xpath>
> <value>string</value>
> </element>
> <!-- -->
> <element>
> <abstractName>resultSetIdleTime</abstractName>
> <actualName>resultSetIdleTime</actualName>
> <occurrence>0-1</occurrence>
> <xpath>/resultSetIdleTime</xpath>
> <value>integer</value>
> </element>
> <!-- -->
> <element>
> <abstractName>items</abstractName>
> <actualName>records</actualName>
> <occurrence>0-1</occurrence>
> <xpath>/records</xpath>
> <value>structured</value>
> </element>
> <!-- -->
> <element>
> <abstractName>nextPosition</abstractName>
> <actualName>nextRecordPosition</actualName>
> <occurrence>0-1</occurrence>
> <xpath>/nextRecordPosition</xpath>
> <value>positiveInteger</value>
> </element>
> <!-- -->
> <element>
> <abstractName>diagnostics</abstractName>
> <actualName>diagnostics</actualName>
> <occurrence>0-1</occurrence>
> <xpath>/diagnostics</xpath>
> <value>structured</value>
> </element>
> <structure element="records">
> <subElement>
> <actualName>recordSchema</actualName>
> <occurrence>1</occurrence>
> <value>string</value>
> </subElement>
> <subElement>
> 
> ......
> <subElement>
> </element>
> .......
> </structure>
> ----------------------------------------------------------------------
> 
> Question.
> 
> Any elements that don't have an abstract name, I don't understand
> how the client will discover anything about them. This applies not
> just to top level elements but also to subelements.  So for example,
> the element <records> is an abstract parameter but the APD says
> nothing about its structure. So where the description language
> describes the subelement recordSchema, how is the client supposed to
> know the its semantics.    
> 
> It seems to me that we need to define abstract elements for these
> subelements, for example recordSchema.  (We have recordSchema as
> an abstract parameter for the request, but I'm talking about
> recordSchema as an element in the response.)  Another example is
> the <record> element (as opposed to the <records> element.  
> It seems this would need to be distinguished in the APD with a
> corresponding abstract element, in this case "item" (as opposed
> to "items").
> 
> 
> Please comment.
> 
> --Ray
> 
> 
> 
>   ----- Original Message ----- 
>   From: Ray Denenberg, Library of Congress 
>   To: search-ws@lists.oasis-open.org 
>   Cc: Ashley Sanders 
>   Sent: Wednesday, April 16, 2008 9:22 AM
>   Subject: description language
> 
> 
>   SWS Committee Members --
> 
>   We need redirect our efforts towards the description language;
> as we said at Thurday's call, aside from Janifer and me, all
> members should focus attention on this.  (Meanwhile Janifer and I
> will work on the openSearch binding and I will work on getting the
> other documents ready for release).
> 
>   Ralph - you weren't at the call Thursday so we have volunteered
> you to work on this.  Larry and Rob agreed to join in the effort.
> So this means Ashley, Ralph, Larry, and Rob.  Matthew -- would you
> be able to help with this?
> 
>   To reiterate what we discussed at the call: the descriptive
> language needs to describe both an arbitrary server and one that
> supports, for example, SRU 1.2. The current draft treats arbitrary
> servers only. The language needs to be powerful and descriptive
> enough that if a server supports, for example, SRU 1.2, it can
> completely describe itself, without ever saying that it supports
> SRU 1.2. If a server supports openSearch it needs to be able to
> describe that via the description language, that is, our
> description language needs to be compatible with the openSearch
> description language. 
> 
>   Could one of you volunteer to quickly draft up a document for
> discussion that treats both SRU 1.2 and openSearch?
> 
>   Any other observations or comments about this?
> 
>   --Ray