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

hello mark.

On 2013-06-24 21:17 , Mark Nottingham wrote:
>> but i have one question about the general registry model: the current draft says that hints MUST have a name (very reasonable, of course), but also that hints MUST have their data model being defined in JSON.
>> http://tools.ietf.org/html/draft-nottingham-link-hint-00#section-5.1
>> living in a world where we have JSON services, XML services, and RDF services, it seems that hard-coding a specific language data model into such a spec (without constraining it in any way) will limit the utility of such a registry.
> It needs *a* data model.

yes, that's definitely true. i think what i'm trying to figure out a 
first is whether there is any precedence of a registry requiring a JSON 
data model, or any other specific language for that matter, for a 
structured values. it seems it's mostly specific micro-syntaxes (if any 
structure beyond identifiers is required), but i am really wondering 
about what people have usually done in similar situations.

>> for example, in the Home Document draft, which is the original source of the link hint idea, the hints were hard-coded with very constrained data models. this made it relatively easy to expose them in a different syntax (in the XML Home Document draft):
>> http://tools.ietf.org/html/draft-wilde-home-xml-01#page-4
>> without getting too much into the details of this specific registry: what are the best practices about allowing/controlling language dependencies in registries?
> Whoa, hold on - who said anything about a language? This is just the underlying data model; you can express it in a document however makes sense.

that's kind of true, but not really. since the draft allows *any* kind 
of JSON, if i had a non-JSON document format (let's say XML ;-) that 
wanted to be able to represent registry values in general, it needs to 
define a generic mapping from *any* kind of JSON to XML. that's 
technically possible, but not really what works well for any non-JSON 
document model.

i think this is my main argument: if you have a micro-syntax for the 
registry, you can map that much easier to something that maps reasonably 
well into a variety of document models. if you require JSON, and allow 
arbitrary JSON, the JSON bias translates into rather inconvenient models 
for any non-JSON language.

>> personally, i would feel more comfortable with having a registry that is of equal value to people regardless of their implementation language
> You're using "language" quite loosely here.

maybe. and like i said above, apart from having implementation concerns 
about non-JSON formats, i am also really interested to learn about prior 
art: how was this problem approached/solved in other situations like this?

>> , but then again that means that the registry itself must define a "mini-language" of its own.
> -1. Defining Yet Another Data Model as a political solution to avoid picking an existing one is sub-optimal at best.

not sure. if JSON is #1 on the requirement list, then maybe define a 
well-defined subset of JSON, so that mappings into other languages don't 
need to be able to handle *any* JSON?

more specifically, what do the current hints actually need? it seems 
that the set of possibilities is actually rather small. for example, 
http://tools.ietf.org/html/draft-nottingham-link-hint-00#section-3.2 
says "Content MUST be an object, whose keys are media types, and values 
are objects", but what are the objects containing? maybe a simple array 
of media type strings would suffice? and then, if we can boil down the 
needs to "hints are strings or arrays of strings", then we can create 
good mappings for a variety of document models, and not just for JSON.

cheers,

dret.

-- 
erik wilde | mailto:[email protected]  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |