W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

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

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Fri, 20 Jan 2012 18:06:16 +1300
Message-ID: <4F18F648.3080502@treenet.co.nz>
To: ietf-http-wg@w3.org
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 

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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:00 UTC