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 |