Re: [apps-discuss] [rest-discuss] Re: New Version Notification for draft-nottingham-link-hint-00.txt
Erik Wilde <dret@berkeley.edu> Tue, 25 June 2013 04:49 UTC
Return-Path: <dret@berkeley.edu>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1507721F9DDC for <apps-discuss@ietfa.amsl.com>; Mon, 24 Jun 2013 21:49:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5GRL8IucQgI for <apps-discuss@ietfa.amsl.com>; Mon, 24 Jun 2013 21:49:06 -0700 (PDT)
Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id 9884721F9DC1 for <apps-discuss@ietf.org>; Mon, 24 Jun 2013 21:49:06 -0700 (PDT)
Received: from 99-38-249-227.lightspeed.sntcca.sbcglobal.net ([99.38.249.227] helo=[192.168.1.68]) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from <dret@berkeley.edu>) id 1UrLBg-0000PJ-Cs; Mon, 24 Jun 2013 21:49:06 -0700
Message-ID: <51C92146.7000309@berkeley.edu>
Date: Mon, 24 Jun 2013 21:49:10 -0700
From: Erik Wilde <dret@berkeley.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: IETF Apps Discuss <apps-discuss@ietf.org>, REST-Discuss <rest-discuss@yahoogroups.com>
References: <20130610033804.19451.29465.idtracker@ietfa.amsl.com> <E6062DBC-CD7B-47CA-A6F0-5E7D64C0DB55@mnot.net> <51B7AEAF.20404@berkeley.edu> <4CD4652F-4EAF-4258-A6EB-577019018D2C@mnot.net>
In-Reply-To: <4CD4652F-4EAF-4258-A6EB-577019018D2C@mnot.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Mark Nottingham <mnot@mnot.net>
Subject: Re: [apps-discuss] [rest-discuss] Re: New Version Notification for draft-nottingham-link-hint-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jun 2013 04:49:13 -0000
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:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret |
- [apps-discuss] Fwd: New Version Notification for … Mark Nottingham
- Re: [apps-discuss] Fwd: New Version Notification … Erik Wilde
- Re: [apps-discuss] New Version Notification for d… Mark Nottingham
- Re: [apps-discuss] [rest-discuss] Re: New Version… Erik Wilde
- Re: [apps-discuss] New Version Notification for d… Stephen Farrell
- Re: [apps-discuss] New Version Notification for d… Mark Nottingham
- Re: [apps-discuss] New Version Notification for d… Stephen Farrell
- Re: [apps-discuss] New Version Notification for d… Erik Wilde
- Re: [apps-discuss] New Version Notification for d… Mark Nottingham
- Re: [apps-discuss] New Version Notification for d… Erik Wilde
- Re: [apps-discuss] New Version Notification for d… Mark Nottingham
- Re: [apps-discuss] New Version Notification for d… Erik Wilde
- Re: [apps-discuss] [rest-discuss] Re: New Version… Matt McClure
- Re: [apps-discuss] New Version Notification for d… Mark Nottingham
- Re: [apps-discuss] New Version Notification for d… Erik Wilde
- Re: [apps-discuss] New Version Notification for d… Graham Klyne