RE: [p3-payload] Media-Type -- Two Values, One Cup Anti-Pattern?

On Friday, January 20, 2012 11:00 AM, Amos Jeffries wrote:
> IMHO the place for adding such instructions is not in the HTTP tokens,
> but in the fields provided by the representation.
> 
> XML itself is perfectly capable of specifying in one of its tags the
> data type that will be produced after unwrapping/processing. So this
> "+"
> syntax is not actually adding "+xml" to a type as it is more along the
> lines of adding redundant "something+" to the text/xml and
> application/xml types alongside how the XML coded representation stores
> that meta data.
> 
> This is in no way the fault of HTTP protocol, but of those designing
> the
> sub-protocols not taking into account the 2-value repercussions and
> nesting options clearly enough.
> ... or perhapse they did, and decided that registering a nested type
> "text/a+b" was the best way to go given the nature of how a and b
> interact.

May I just ask a quick question on this. We are currently working on a
JSON-based media type (JSON-LD) and plan to use the application/ld+json
media type for it. Do you think that's a bad practice?

Unfortunately in JSON there's no way to specify such processing instructions
within the representation as you propose. From looking at the current
registered media types and discussions with a number of people (mostly from
the WHATWG) we thought that's the best practice, so I'm a bit confused now.

A related issue we stumbled into is how we define further "subtypes". E.g.
we will need a way to describe a "JSON-LD frame". The first idea was to use
application/frame-ld+json but some people argued that the best practice
would be to use application/frame+ld+json which looks weird to me.

So, in these concrete examples, what would you (and others) propose to use?

P.S.: I fear I will get a response that says: it's an opaque identifier and
it doesn't matter



--
Markus Lanthaler
@markuslanthaler

Received on Friday, 20 January 2012 04:11:42 UTC