W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2008

Re: issue 85 - range unit extensions

From: Kris Zyp <kris@sitepen.com>
Date: Tue, 2 Sep 2008 17:55:43 -0600
Message-ID: <0dc301c90d57$6a685cb0$4200a8c0@kris>
To: "Jamie Lokier" <jamie@shareable.org>
Cc: "Robert Brewer" <fumanchu@aminus.org>, "Yves Lafon" <ylafon@w3.org>, "Julian Reschke" <julian.reschke@gmx.de>, <ietf-http-wg@w3.org>

>> >I'm a bit surprised that the top-level object in a JSON request would
>> >be an array, though.  For round-trip minimisation in AJAX applications
>> >isn't it usual to send a bit of auxiliary metadata, or a few objects
>> >together, and therefore the top-level JSON object tends to be an
>> >object (i.e. several named data items) with one of its members being
>> >an array, rather than the top-level object being an array itself?
>> I am trying to move away from that approach, moving metadata to headers
>> (ironically the offset and total count are the most common metadata 
>> items,
>> and these are handled by the Content-Range header), allowing the actual
>> content to be a "pure" representation of the resource, and therefore an
>> array is the most natural top-level construct when requesting a 
>> collection
>> of objects.
> Unfortunately, putting metadata into headers isn't a very tidy way of
> representing metadata which has structure itself, which is not
> uncommon with JSON.

Not wishing to infer assent, but could we presume that if an alternate JSON 
structure was defined that had a top level object with prescribed property 
containing the array/items, that it could have application content type 
which provided the definition of how it should be segmented in response to 
an Range: items request? I think it is assumed that creating subset 
representations via a items range is content type specific (it would 
certainly be different for XML, for example), so it seems reasonable that 
application sub-types could also provide a definition of item range unit 
(Concatenation can still remain content-type agnostic)


> -- Jamie
Received on Tuesday, 2 September 2008 23:57:48 UTC

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