Re: [apps-discuss] New Version Notification for draft-nottingham-link-hint-00.txt
Erik Wilde <dret@berkeley.edu> Thu, 27 June 2013 00:24 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 08AE811E8170 for <apps-discuss@ietfa.amsl.com>; Wed, 26 Jun 2013 17:24:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.949
X-Spam-Level:
X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 kjFVRWIlQDuS for <apps-discuss@ietfa.amsl.com>; Wed, 26 Jun 2013 17:24:47 -0700 (PDT)
Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id F0A6F11E8155 for <apps-discuss@ietf.org>; Wed, 26 Jun 2013 17:24:46 -0700 (PDT)
Received: from mobile-166-137-186-253.mycingular.net ([166.137.186.253] helo=dretpro.local) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from <dret@berkeley.edu>) id 1Us00w-0002ES-57; Wed, 26 Jun 2013 17:24:43 -0700
Message-ID: <51CB8646.60101@berkeley.edu>
Date: Wed, 26 Jun 2013 17:24:38 -0700
From: Erik Wilde <dret@berkeley.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Mark Nottingham <mnot@mnot.net>
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> <1A136C4D-4F0C-446F-B307-D53FB9A40622@cs.tcd.ie> <8BE038EC-1580-4D27-ABBA-1890EEFD4853@mnot.net> <51C9C91D.90206@berkeley.edu> <4C2FD8A7-4F3E-433B-A7F6-F0BD751D31AD@mnot.net> <51CB240C.3060101@berkeley.edu> <F2662B38-CDD6-401D-85F8-438FF67AFAFF@mnot.net>
In-Reply-To: <F2662B38-CDD6-401D-85F8-438FF67AFAFF@mnot.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: IETF Apps Discuss <apps-discuss@ietf.org>, REST-Discuss <rest-discuss@yahoogroups.com>
Subject: Re: [apps-discuss] 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: Thu, 27 Jun 2013 00:24:51 -0000
hello mark. On 2013-06-26 16:40 , Mark Nottingham wrote: > On 27/06/2013, at 3:25 AM, Erik Wilde <dret@berkeley.edu> wrote: >>> 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. > Yep, this is where we're at. >> - 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. i agree that this is not such a great way to go. it makes things easy in the short run, but harder in the long run. in particular, it means that the same concepts ("a list") may be serialized differently in different hints (a "comma-separated" one, a "space-separated" one), which makes it harder to build general facilities for hints. >> - 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. >> 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? > Could you spell out an example? afaict, "formats" (http://tools.ietf.org/html/draft-nottingham-link-hint-00#section-3.2) right now says says it's an object with the keys being media types, but the values are not specified. but maybe i am reading it wrong and where it says "The object" in the second and third paragraph it actually refers to the object that's a value of one of the keys? hmmm, i guess that's what it means... i had been reading it wrong so far. but for a minute, let's just assume it's only media types, which is how i am using it in an example using link hints here: https://github.com/dret/I-D/blob/master/link-desc/ld-atompub-00.xml so let's assume for a minute that this is just a list. then i would suggest is the following: the hint is defined as follows (stealing your structure here): o Hint Name: formats o Description: Hints the representation type(s) that the target resource can produce and consume, using the GET and PUT (if allowed) methods respectively. o Content Model: list o Specification: [this document] Content MUST be a list, whose values are media types. then, the term "list" in the content model must be defined somewhere. like i said, maybe we could say there are three "content models" hints support: single values, lists, key/value pairs. how a particular hint value would be serialized then would be up to the format where it's being represented. - in JSON, you might represent them as string, array, something else. - in XML, you might choose a mix of element/attribute designs. or you could go text-based such as my example (which is text-based because it uses JSON syntax right now) none of these representations would be binding, they would just be one way of mapping the abstract link hint model into some concrete model. i guess the only exception for this would be how to represent links outside of media types, i.e. in HTTP. http://tools.ietf.org/html/draft-nottingham-link-hint-00#appendix-A could be changed then to map the abstract moden into a concrete JSON syntax (or whatever else looks like a good syntax choice to go into a Link header). as i see it, when i design media types that use link hints, it would be nice if i could expose them in a way that is as useful as possible for consumers of that media type. my example from above is from an XML design for link descriptions that i plan to base on link hints. if that means that the XML-oriented clients using this format need to include a general-purpose JSON parser, then that's certainly doable, but i don't think the link hints design has to be like that. but again, of course my option (c) means that link hints have a predefined and probably small set of structures that hints can use to expose whatever they want to expose, and if they want to go beyond that, that's not covered by the link hint framework anymore. 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