sru:recordPacking = unpacked ?

["Hammond, Tony" <t.hammond@nature.com>]

Hi:

I have a requirement for handling SRU record data to make it accessible
within an OpenSearch context. Essentially I need to "unpack" the record
data.

To explain this scenario I will use the example "Atom extension for SRU"
format [1] which is posted on the TC site.

This is a good start to the item level SRU mapping. So, for a result set
delivered in the "srw_dc" schema I might have something like:

<title>
<link>
<sru:recordSchema>...</sru:recordSchema>
<sru:recordPacking>...</sru:recordPacking>
<sru:recordData>
  <srw_dc>
    <dc:title>
    <dc:creator>
 </srw_dc>
</sru:recordData>
<sru:recordPosition>...</sru:recordPosition>

This is good from an SRU point of view but not so good from an OpenSearch
point of view as the search response elements ("dc:title", "dc:author") are
buried two levels down in the element hierarchy.

And this is significantly worse in my own use case of PAM, or PRISM
Aggregator Message, where there are two more wrapper elements intervening.
So I would have this:

<sru:recordData>
  <pam:message>
    <pam:article>
      <xhtml:header>
        <dc:title>
        <dc:creator>
     </xhtml:header>
   </pam:article>
 </ pam:message>
</sru:recordData>

From an OpenSearch point of view what I really need is this:

<title>
<link>
<dc:title>
<dc:creator>
<sru:recordSchema>...</sru:recordSchema>
<sru:recordPacking>...</sru:recordPacking>
<sru:recordData/>
<sru:recordPosition>...</sru:recordPosition>

That is, I need something akin to an "unpacked" option, so that my search
response elements are immediately available at the toplevel and not buried
within a hierarchy. The reason for this is not so much technical (although
it is that too) but is to do with mindshare. If it's too hard nobody will
bother and SRU is the loser. (SRU must accommodate OpenSearch, not the other
way round.)

Note that we already have the request parameter "recordPacking" which takes
two values "xml" and "string". (And frankly, not doing very much IMHO. Badly
formed XML is already something outside of the SRU conventions - schema then
amounts for nothing.)

(I believe this is the right parameter to focus on rather than introduce a
new parameter, e.g. "recordDataPacking".)

I wonder if it would be possible to either a) overload this parameter, or b)
substitute the application of this parameter, so that the following cases
could be requested:

    a) recordPacking = packed

    b) recordPacking = flattened

    c) recordPacking = unpacked

The first case a) would be the standard SRU offering, the second case would
allow for properties to bubble up to the <recordData> container element, and
the third case c) would allow for properties to escape the SRU response
entirely and be directly available to the host format (e.g. Atom in this
example).

Note that the "unpacked" option would not apply to native SRU response XML
which has nowhere to put this data - there is no "outside".

Note also that the "flattened" option may be too much to think about. It is
a logical possibility but may just complicate matters.

So, the three cases could look as folows:

a) recordPacking = packed

<title>
<link>
<sru:recordSchema>...</sru:recordSchema>
<sru:recordPacking>...</sru:recordPacking>
<sru:recordData>
  <srw_dc>
    <dc:title>
    <dc:creator>
 </srw_dc>
</sru:recordData>
<sru:recordPosition>...</sru:recordPosition>


b) recordPacking = flattened

title>
<link>
<sru:recordSchema>...</sru:recordSchema>
<sru:recordPacking>...</sru:recordPacking>
<sru:recordData>
  <dc:title>
  <dc:creator>
</sru:recordData>
<sru:recordPosition>...</sru:recordPosition>

c) recordPacking = unpacked

<title>
<link>
<dc:title>
<dc:creator>
<sru:recordSchema>...</sru:recordSchema>
<sru:recordPacking>...</sru:recordPacking>
<sru:recordData/>
<sru:recordPosition>...</sru:recordPosition>


Of course, we still have the existing values for "recordPacking" which, if
required still, could be accommodated by adopting a value list strategy,
similar to "sortKeys", e.g. we could have

    * recordPacking = xml

    * recordPacking = xml, packed

    * recordPacking = xml, flattened

    * recordPacking = xml, unpacked

and same for "string".

It could be argued that an "unpacked" record data is no longer a valid SRU
response, but I would counter that not all responses have recoprd data, e.g.
where diagnostics are provided. Also, even in an "unpacked" scenario with an
empty "recordData" element (or missing element) we have said something about
the data: that is was there but has been processed ("unpacked").

I would like to hear some responses to this proposal as I will very shortly
have to go ahead and implement search responses for the service we are about
to release. I would like to be as fully SRU compatible as possible but also
making it a breeze for OpenSearch users. I believe that the current proposal
(or something very much like it) would allow for both perspectives to be
maintained.

Cheers,

Tony


[1] 
http://www.oasis-open.org/committees/download.php/33408/atom-extension-for-s
ru.xml
[2] 
http://www.crossref.org/CrossTech/2009/07/opensearch_formats_for_review.html


********************************************************************************   
DISCLAIMER: This e-mail is confidential and should not be used by anyone who is
not the original intended recipient. If you have received this e-mail in error
please inform the sender and delete it from your mailbox or any other storage
mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
liability for any statements made which are clearly the sender's own and not
expressly made on behalf of Macmillan Publishers Limited or one of its agents.
Please note that neither Macmillan Publishers Limited nor any of its agents
accept any responsibility for viruses that may be contained in this e-mail or
its attachments and it is your responsibility to scan the e-mail and 
attachments (if any). No contracts may be concluded on behalf of Macmillan 
Publishers Limited or its agents by means of e-mail communication. Macmillan 
Publishers Limited Registered in England and Wales with registered number 785998 
Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS   
********************************************************************************