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

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

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
>