[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]