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

Erik Wilde <[email protected]> Tue, 11 Jun 2013 16:11:43 -0700
Newsgroups gmane.comp.web.services.rest,gmane.ietf.apps-discuss
Message-ID <[email protected]>
On 2013-06-09 20:38 , Mark Nottingham wrote:
>> Filename:	 draft-nottingham-link-hint
>> Revision:	 00
>> Title:		 HTTP Link Hints
>> Creation date:	 2013-06-10
>> Group:		 Individual Submission
>> Number of pages: 12
>> URL:             http://www.ietf.org/internet-drafts/draft-nottingham-link-hint-00.txt
>> Status:          http://datatracker.ietf.org/doc/draft-nottingham-link-hint
>> Htmlized:        http://tools.ietf.org/html/draft-nottingham-link-hint-00
>> Abstract:
>>    This memo specifies "HTTP Link Hints", a mechanism for annotating Web
>>    links to HTTP(S) resources with information that otherwise might be
>>    discovered by interacting with them.

generally speaking, i think this might become a very useful way how 
various services can expose more helpful links to clients, if they 
choose to do so, and if the clients are interesting in taking that 
information into account.

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. 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? personally, i would feel more comfortable 
with having a registry that is of equal value to people regardless of 
their implementation language, but then again that means that the 
registry itself must define a "mini-language" of its own.

any pointers to similar situations and how they were resolved would be 
greatly appreciated. thanks and 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 |