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


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 -----
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 sever 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
 
 
 


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