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] Re: description language


There's nothing in an explain record that tells you how to find things
in responses.  Explain helps you interpret what you find.

Explain is about the server describing what it can do.  We are trying to
describe how to talk to the server.  You clearly need both for a
satisfying user experience and we'll probably end up munging them
together somehow.

Ralph

> -----Original Message-----
> From: Larry E. Dixson [mailto:ldix@loc.gov]
> Sent: Monday, April 21, 2008 11:55 AM
> To: Ray Denenberg, Library of Congress
> Cc: search-ws@lists.oasis-open.org; Ashley Sanders
> Subject: Re: [search-ws] Re: description language
> 
> 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_desc
> ription_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
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and 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]