Mike Amundsen

hmm.... good point! proly why i'd used "image" in the original design! so, i suspect that the use of "embed" will also mean the need for a type hint similar...

yeah - that's the implication here. the optional use of "type" property on any data element to help the client know how to augment/narrow the request to the server for...

yep - this is the outcome. adding "type" to data elements increases the CR factor within the representation itself (other CR factors (i.e. the method and format to use) are...

frankly, i'm a bit hesitant to add more factors into this particular design. i can see the value here, tho. mca+1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://www.linkedin.com/in/mikeamundsen On Mon, Oct...

yep - you're right on there. i'd like to keep the parsing/computing complications at runtime relatively low. this limits the "express-ability" (LOL) of reprsentations in CJ, but increases the chances...

yeah - this case is ok. i am speaking in general here, too. keeping this particular design rather basic in regards to inline H-Factors is a goal for me; that's...

it spreads what is basically a link information (like in Web Linking) over the value and type properties, when in fact that belongs to something like "value": {"href":"...", "type":"{mimetype}"... but...

Sebastian: That's a good question. I don't have any plans at the moment, but I can see it might be helpful. first, to support PATCH, we'd need to select a...

yes, JSON-Patch does seem rather involved. again, i haven't spent enough time w/ it to make a clear judgement. PARTIAL UPDATE EXTENSION first, if you'd like to implement your own...

@evert thanks for submitting these -- all good additions. i'll review the ketting links you provided to help influence the mods. as you mentioned, i'm going to break this up...