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
>
|