Re: [search-ws] recordPacking: No Schema Change Required

["Ray Denenberg, Library of Congress" <rden@loc.gov>]

"Sorry, I'm resisting solving this problem until we get a clear
requirements statement."


Ok, Tony would have to confirm but this is my understanding.

To begin with, there is an assumption that for a given response format, 
let's say for example ATOM, there will be mapping defined from the standard 
SRU response (application/sru+xml) to ATOM.

In fact an ATOM extension has been sketched for this purpose, 
http://www.oasis-open.org/apps/org/workgroup/search-ws/download.php/33410/atom-extension-for-sru.doc.

If you look at that example SRU/ATOM response, I believe the requirement is 
that the actual record data ......

e.g.
<creator>Gaiman, Neil.</creator>

<type>text</type>

<publisher>London : Titan,</publisher>

<date>2002.</date>

<language>eng</language>



...... be elevated so that it is not nested so deeply within the response.



Tony gives an example of how he might want the data serialized in this 
message:

http://www.oasis-open.org/apps/org/workgroup/search-ws/email/archives/200908/msg00012.html



That shows two serializations, one according to  the "standard" ATOM 
extension, and the second, an alternative.   The requirement, then, is to 
indicate that the alternative serialization is desired.



Now I know you can say, why not just define a second ATOM extension.  This 
raises the question of how we're going to ask for the ATOM extension in the 
first place.  Remember, we have to specify a mime type. Is 
application/atom+xml going to mean "the SRU ATOM extension"?  Or are we 
going to have to register a mime type for it? Unlikely we'd be able to do 
that. So one approach would be that application/atom+xml is specified as the 
mime type and that there would be another parameter to further refine the 
response type.



--Ray



----- Original Message ----- 
From: "LeVan,Ralph" <levan@oclc.org>
To: "Ray Denenberg, Library of Congress" <rden@loc.gov>; "OASIS SWS TC" 
<search-ws@lists.oasis-open.org>
Sent: Tuesday, September 29, 2009 9:10 AM
Subject: RE: [search-ws] recordPacking: No Schema Change Required


Sorry, I'm resisting solving this problem until we get a clear
requirements statement.

Ralph

> -----Original Message-----
> From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
> Sent: Monday, September 28, 2009 5:03 PM
> To: OASIS SWS TC
> Subject: Re: [search-ws] recordPacking: No Schema Change Required
>
> Yes, it really is about the entire response, however the effect on the
> entire response may be  affected (i.e. may vary according to) the
specfic
> record schema.
>
> How about responseSubSchema?  The protocol itself would not define any
> values, or maybe just one or so, and it would be up to someone who
defines a
> response format to  say "if xyz is specified for the value of
> responseSubSchema then that means that the following variation of this
> format is desired".  Or
>
> "if xyz is specified for the value of responseSubSchema, and if DC is
> specified for recordSchema, then ...; but if xyz is specified and if
MODS is
> specified for recordSchema, then ..."
>
> --Ray
>
> ----- Original Message -----
> From: "LeVan,Ralph" <levan@oclc.org>
> To: "Ray Denenberg, Library of Congress" <rden@loc.gov>; "OASIS SWS
TC"
> <search-ws@lists.oasis-open.org>
> Sent: Monday, September 28, 2009 12:51 PM
> Subject: RE: [search-ws] recordPacking: No Schema Change Required
>
>
> I think we need to back up and try again.  We seem to be disagreeing
on
> the fundamental issue of what is being described here.  To me this is
> clearly not about record schemas because the change is to the entire
> response, not just the record part.
>
> I think we need to understand the actual requirement better.  But, I
> think we've made good progress here.
>
> Ralph
>
> > -----Original Message-----
> > From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
> > Sent: Monday, September 28, 2009 12:29 PM
> > To: OASIS SWS TC
> > Subject: Re: [search-ws] recordPacking: No Schema Change Required
> >
> > No, recordFormat is not a good name, I just threw it out there for
> lack of a
> > better suggestion at the time, my main point was to ask is it a good
> idea or
> > not to make this a separate parameter.
> >
> > But responseSchema isn't right.  This isn't at the response schema
> level, it
> > is at the record schema level.  We already have a recordSchema
> parameter,
> > this is sort of a "record sub-schema".    How about recordSubSchema
> for the
> > parameter name?
> >
> > --Ray
> >
> >
> >
> > ----- Original Message -----
> > From: "LeVan,Ralph" <levan@oclc.org>
> > To: "Ray Denenberg, Library of Congress" <rden@loc.gov>; "OASIS SWS
> TC"
> > <search-ws@lists.oasis-open.org>
> > Sent: Monday, September 28, 2009 9:31 AM
> > Subject: RE: [search-ws] recordPacking: No Schema Change Required
> >
> >
> > > -----Original Message-----
> > > From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
> > >
> > > recordPacking=looselyPacked&httpAccept=application/xyz
> > >
> > >...
> > >
> > > I'm not opposed to adding this functionality. I just think that it
> > stretches
> > > the semantics of the recordPacking parameter too far. How about if
> we
> > > introduce another parameter, call it 'recordFormatting'.
> >
> > I'm not sure that recordFormat is the right name.  This is not about
> how
> > records appear, but about the complete response.  I suggest that we
> call
> > it 'responseSchema'.  Its semantic is that it names the content to
be
> > returned.
> >
> > A problem with the new responseSchema parm is that its potential
> values
> > are constrained by the media-type that it is associated with.  We're
> > going to have to add a media-types section to Explain (necessary
> anyway)
> > and within that, list the responseSchemas available.  There will be
an
> > implicit default text/xml media-type with a default value of
> > searchRetrieveResponse associated with SRU Explain records.
> >
> > <mediaTypeInfo>
> >     <mediaType value="application/json">
> >         <responseSchema name="unpacked"
> > identifier="http://nature.com/responseSchemas/unpacked";>
> >             <title>JSON with SRU record element data added</title>
> >             </responseSchema>
> >         </mediaType>
> >     </mediaTypeInfo>
> >
> > I'm not going to be horrified to discover that we need to add
> > recordSchema as a sub-element of mediaType too.
> >
> > Ralph
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  Follow this link to all your TCs in OASIS at:
> >
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  Follow this link to all your TCs in OASIS at:
> >
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>