Re: [apps-discuss] New Version Notification for draft-nottingham-link-hint-00.txt

Erik Wilde <[email protected]> Wed, 26 Jun 2013 10:25:32 -0700

Newsgroups	gmane.comp.web.services.rest,gmane.ietf.apps-discuss
Message-ID	<[email protected]>

hello mark.

On 2013-06-25 23:51 , Mark Nottingham wrote:
>> i really like the places where it says "a number" and "a list", because these concepts can be easily mapped into pretty much any representation. when it says "an object", however, that's an entirely different matter. it would be great for the registry to really be clear about what kind of structures to expect for hints (single values, value lists, and maybe lists of key/value pairs or something along those lines), and then the registry would not depend on a specific language.
> It's certainly possible to map the JSON data model into XML; it just won't make XML people happy, because it'll have lots of elements named "object" and "array" (although I see a fair amount of "native" XML like this anyway!).

sure, with enough effort, anything can be mapped to anything. my point
was to have something for the link hints that can be mapped into more
useful structures for any target mapping, and not just for JSON.

> I very much agree that it would be good to not have a dependency upon the JSON data model here. However, I don't see a way to avoid that, without either a) using another data model with exactly the same problem, or b) prohibiting any structured information.
> AIUI you're suggesting (b). Looking through the current list of hints, we already have quite a few that need structure. Can you suggest how to convey the information without using structured data?

i think there are three possibilities:

- pick a generic format (such as JSON) as allow anything it allows. this
makes things great for JSON and not so great for non-JSON.

- be structure agnostic (hints are strings) and then hints will probably
define their own mappings into string-based structures (using regexes
and usual patterns such as whitespace- or comma-separated lists). this
might be bad because then parsing a hint's value needs to be done on a
per-hint basis.

- pick a small set of structures allowed such as the ones i suggested
above (single values, value lists, and maybe lists of key/value pairs)
and require that any hint is defined in terms of this more restricted
model. this maps better to many formats, but you're stuck with the
choices you make.

so my suggestion is not so much your (b) but my (c) ;-) fwiw, it seems
that thew current draft uses overly complicated structures, for example,
"formats" maybe just could be an array of formats?

it's clearly a trade-off between allowing arbitrarily structured hints
(in which case you need some generic metamodel) or predefining the kinds
of structures that hints can use (in which case you can remove the
dependency on a particular generic metamodel). i am still trying to
understand how that problem has been solved in similar cases. i assume
this is not the first (proposed) IANA registry that has to deal with
this tradeoff; does anybody have pointers to this has been handled in
similar cases?

thanks and cheers,

dret.