Sorry, I'm resisting solving this problem until we get a clear
requirements statement.
Ralph
> -----Original Message-----
> From: Ray Denenberg, Library of Congress [mailto:]
> 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" <>
> To: "Ray Denenberg, Library of Congress" <>; "OASIS SWS
TC"
> <>
> 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:]
> > 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" <>
> > To: "Ray Denenberg, Library of Congress" <>; "OASIS SWS
> TC"
> > <>
> > 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:]
> > >
> > > 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
>
