19484Re: [apps-discuss] New Version Notification for draft-nottingham-link-hint-00.txt
- Jun 26, 2013On 27/06/2013, at 3:25 AM, Erik Wilde <dret@...> wrote:
> hello mark.Yep, this is where we're at.
> 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.I'm -1 on this; it hasn't worked out so well for HTTP headers (and in fact a significant number of people are agitating to just define new headers in JSON) nor for media type parameters.
> - 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.Could you spell out an example?
> 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?Cheers,
> thanks and cheers,
Mark Nottingham http://www.mnot.net/
- << Previous post in topic Next post in topic >>