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
