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

On 20/01/2012 5:11 p.m., Markus Lanthaler wrote:
> 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.

May or may not be best practice under the type specs. My point was that 
it is under *those* specs rather than HTTP ones that type syntax points 
being argued fall.

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

Pretty much, although "don't care" instead of "doesn't matter" (because 
it might matter, for you).

Its a personal preference on my behalf not to like needless duplication. 
The XML case is particularly offensive in that the type says "ZZ+xml" 
then the very first tag in the XML itself says essentially "wrapped ZZ". 
Which is a waste of bytes in the HTTP layer and lead to this threads 
confusion.

AYJ

Received on Friday, 20 January 2012 05:06:58 UTC