Print

Print


No.

So, according to the relevant standards, all content types need to be 
registered, you don't just get to make them up -- unless you use some of 
the prefixes for experimental/vendor/unregistered content types.

Not even if they end in "+xml" do you get to make them up.

There is, however, an established convention in the standard that 
content types ending in "+xml" are XML

There is no equivalent established standard for content types ending in 
"+json", even if you think it is "sort of implied."

The "+xml" convention is standardized in this RFC: 
http://tools.ietf.org/search/rfc3023

I don't believe a "+json" convention is standardized anywhere, although 
I don't think there's anything stopping you from ending any content type 
you want in "+json" ("+" is a legal char for content types in general, I 
think?), and I can see how it would be a helpful hint for developers.

You would still need to register your content type, or use one of the 
vendor/experimental/private-use prefix standards, as you would for any 
new content type, ending in "+xml", "+json", or anything else. Or at 
least, you'd need to do that unless you are okay with violating the 
standards.

I do encourage looking at RFC3023 to get a sense of how all this stuff 
works, especially it's FAQ section at the end.

Jonathan

On 2/19/14 10:57 AM, Ray Denenberg wrote:
> *From:*LeVan,Ralph
>
>  > Application/sru+xml means SRU returned as XML.
>
> It means more than that. it means that the response must be as defined
> by the SRU Response schema:
>
> http://docs.oasis-open.org/search-ws/searchRetrieve/v1.0/os/schemas/sruResponse.xsd
>
>
> That sort of implies
>
>  > that application/sru+json is meaningful.
>
> Not unless (or until) there is an analogous json schema.
>
>  > The HTTP Accept header or the httpAccept parameter take care of the
>
>  > response definition, possibly supplemented with the responseType
>
>  > parameter if a sufficiently complicated media subtype canít be agreed
>
>  > upon. (In the example given below of an Atom response with SRU
>
>  > semantics, it was suggested that the media type would be
>
>  > application/atom+xml combined with a response type (essentially) of SRU.
>
> No, it's saying more than just "atom expressing SRU", it is saying there
> is a (fictitious) definition (which may be a schema, or some other form
> of definition) whose identifier is *info:srw/1/response-type/atom, * to
> be used in conjunction with atom, to form a complete SRU response.
>
>  > To my mind what that means is that we are refining the Atom semantics
>
>  > with SRU semantics. Iíd probably fudge the whole thing as
>
>  > application/atom.sru+xml, realizing that no one has agreed to the
>
>  > semantics of that media type. :)
>
> By that approach we either (a) fudge non-standard media types, or (b)
> try to standardize the media types we want.   I don't like either
> possibility.
>
>  > A similar pattern then applies for the record.  I need to specify a
>
>  > media type with semantics and syntax combined.  Application/marc21+xml,
>
>  > application/vnd.viaf+xml, application/vnd.viaf+json.  The current
>
>  > solution is to provide an opaque URI in the recordSchema parameter (or
>
>  > a short name for that URI as defined in the Explain record) that
>
>  > magically defines semantics and syntax.
>
> And what's wrong with the latter?
>
>  > I think I prefer a more explicit use of an Internet media type.  It is
>
>  > subject to standard rules about negotiation with the client and server
>
>  > both able to say something about the ranking of preferences.  The
>
>  > recordSchema element in the record response allows the server to tell
>
>  > the client what media type was selected for the response.
>
> I think you meant to say "selected for the record"?  But no, the server
> doesn't select a record syntax, that value is echoed in the response,
> redundantly. The server cannot select an alternative syntax.  At the
> (broader) response level, it's different. The client has the option of
> content negotiation, as an alternative to using httpAccept, and, this
> way to do it (allowing both mechanisms)  was chosen (and as I recall, it
> was your idea) for two reasons (1) we wanted to allow content
> negotiation, (2) some clients are not capable of content negotiation.
>
> But my point, I think, is that content negotiation is meaningful at the
> response level, but doesn't really make a whole lot of sense at the
> record level.
>
>  >     The critical standards issue here is that the client needs
>
>  > to be able to request something *not* on our approved list of options
>
> I don't follow, could you elaborate?
>
>  >
>
>  > recordXMLEscaping (formerly recordPacking) is a specific example of a
>
>  > generic problem.  I might like to escape my json records in my json
>
>  > response so that they donít get parsed as part of the entire payload.
>
>  > More importantly, I *probably* need to escape my JSON records in my XML
>
>  > response.  I think we need to reconsider recordPacking.
>
> Yes, I do see the point here. I'm sure it will be on the table for 2.1.
>
> Thanks Ralph.
>
> Ray
>
>
> *Sent:* Tuesday, February 18, 2014 4:21 PM
> *To:* [log in to unmask]
> *Subject:* Re: SRU recordPacking and JSON
>