- From: Eric J. Bowman <eric@bisonsystems.net>
- Date: Thu, 19 Jan 2012 21:42:22 -0700
- To: "Markus Lanthaler" <markus.lanthaler@gmx.net>
- Cc: <ietf-http-wg@w3.org>
"Markus Lanthaler" wrote: > > 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? > I have no idea the status of that media type as a proposed standard. If it is, then I still don't know if it's bad practice as I have no idea what your system even does. > > Unfortunately in JSON there's no way to specify such processing > instructions within the representation as you propose. > There's more than one way to use JSON in a system, if you need to do something out-of-scope to JSON, you should consider a different media type. > > 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. > >From looking at the string "application/ld+json", even though I don't know what "ld" means, I know that the sender's intended processing model is JSON-based, so I can parse it in javascript and get objects, fwiw. > > 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 > If you aren't going to standardize /frame-ld+json, then the appropriate syntax and registration procedure is for the vnd. tree, i.e. application/vnd.frame-ld+json. > > but some people argued that the best practice would be to use > application/frame+ld+json which looks weird to me. > The guidelines are being rewritten to include "+json" etc. right now, I doubt multiple "+" syntax will be allowed. What you have there isn't what suffixes are meant to do, at all. > > So, in these concrete examples, what would you (and others) propose > to use? > I don't see any concrete examples to base any sort of proposal on, nor is this the proper list for that, stick with rest-discuss. > > P.S.: I fear I will get a response that says: it's an opaque > identifier and it doesn't matter > I should hope not. URIs are opaque, media types map to processing models; the sender's intended processing model for the payload had better not be opaque or the Web wouldn't work. -Eric
Received on Friday, 20 January 2012 04:42:48 UTC