Re: description language

From
Ray Denenberg, Library of Congress <>
Date
2008-04-21T15:21:18+00:00
ID
12c801c8a3c3$433a65f0$
Thread
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 ----- 

  
From: 
  Ray Denenberg, Library of 
  Congress 

  
To:  
  

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