Re: New Version Notification for draft-divilly-atom-hierarchy-01
Al Brown <albertcbrown@us.ibm.com> Mon, 08 June 2009 22:56 UTC
Return-Path: <owner-atom-syntax@mail.imc.org>
X-Original-To: ietfarch-atompub-archive@core3.amsl.com
Delivered-To: ietfarch-atompub-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA02F28C116 for <ietfarch-atompub-archive@core3.amsl.com>; Mon, 8 Jun 2009 15:56:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.508
X-Spam-Level:
X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, SARE_OBFU_SPLIT_HR2=0.183, TVD_FW_GRAPHIC_NAME_MID=0.543]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egS7ktMn3geX for <ietfarch-atompub-archive@core3.amsl.com>; Mon, 8 Jun 2009 15:56:23 -0700 (PDT)
Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id B637E3A6BC6 for <atompub-archive@ietf.org>; Mon, 8 Jun 2009 15:56:22 -0700 (PDT)
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58MjCSI027278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 15:45:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n58MjCKl027277; Mon, 8 Jun 2009 15:45:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58MjCPJ027271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <atom-syntax@imc.org>; Mon, 8 Jun 2009 15:45:12 -0700 (MST) (envelope-from albertcbrown@us.ibm.com)
Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e31.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n58MeuYW016286 for <atom-syntax@imc.org>; Mon, 8 Jun 2009 16:40:56 -0600
Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n58MjBaZ258714 for <atom-syntax@imc.org>; Mon, 8 Jun 2009 16:45:11 -0600
Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.13.1/8.13.3) with ESMTP id n58Mjj8Z017395 for <atom-syntax@imc.org>; Mon, 8 Jun 2009 16:45:45 -0600
Received: from d03nm133.boulder.ibm.com (d03nm133.boulder.ibm.com [9.17.195.180]) by d03av06.boulder.ibm.com (8.13.1/8.12.11) with ESMTP id n58Mjj7C017390; Mon, 8 Jun 2009 16:45:45 -0600
In-Reply-To: <0C987BDE-612B-4DB1-9B10-8A6A8F5515CD@oracle.com>
References: <20090605170645.A922728C10F@core3.amsl.com> <D29129D3-6D02-417D-AA18-78FCB7CF4E12@oracle.com> <OFD77552CC.EF05D1F7-ON882575CC.006E3712-882575CC.0073EA7D@us.ibm.com> <4A2D5EDC.1020207@gmail.com> <OF0E5CEE35.559023E6-ON882575CF.0077F470-882575CF.0079DF91@us.ibm.com> <0C987BDE-612B-4DB1-9B10-8A6A8F5515CD@oracle.com>
Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-01
X-KeepSent: F6C94627:F2D911AC-882575CF:007C33F4; type=4; name=$KeepSent
To: "Nikunj R. Mehta" <nikunj.mehta@oracle.com>
Cc: atom-syntax Syntax <atom-syntax@imc.org>, James M Snell <jasnell@gmail.com>
X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009
Message-ID: <OFF6C94627.F2D911AC-ON882575CF.007C33F4-882575CF.007CF665@us.ibm.com>
From: Al Brown <albertcbrown@us.ibm.com>
Date: Mon, 08 Jun 2009 15:44:55 -0700
X-MIMETrack: Serialize by Router on D03NM133/03/M/IBM(Build V851_04282009|April 28, 2009) at 06/08/2009 16:45:10
MIME-Version: 1.0
Content-type: multipart/related; Boundary="0__=07BBFF5CDFEFB5648f9e8a93df938690918c07BBFF5CDFEFB564"
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Nikunj wrote: > Al Brown wrote: b. add a new attribute to link that specifies if they are inlined (down) <link rel="down" href="http://www.example.com/foo/down" /> (down-tree) <link rel="down" ah:inlined="true" href=" http://www.example.com/foo/down/inlined" /> This adds complexity if there are cardinality constraints on link relations such as alternate and clients not aware of I-D may think they are the same. >IMHO, ah:inlined does nothing because the presence of ae:inline makes it plenty clear. If you were trying to say that there is a certain level of depth in the tree, may >be an attribute would help, but even then you don't know what things the server may have elided from every entry. So, bottom line is, there is not much value to an >attribute to describe the thing that is in-lined. You are best off using what you have received as an approximation and then get the exact representation if you care so >much in a separate network call. Of course, out-of-band communication or specialized mark-up may provide enough information for you to avoid such round-trips. Maybe I did not explain clearly enough - this is a protocol/hypermedia issue. How does the client say (follow the right link relation) I want an inlined representation of this resource specified by a link relation? E.g., Client (C) navigates to this atom entry (A) somehow. A wants to advertise to the client that A has references to two to representations for resource B. One version of B is flat (ala a feed). One version of B is the same flat feed with its link relations inlined (ala tree). How can resource A provide the client C with information there are two choices available for B (flat vs tree)? -Al Al Brown Emerging Standards and Industry Frameworks CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of the person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify the sender. Please also permanently delete all copies of the original message and any attached documentation. From: "Nikunj R. Mehta" <nikunj.mehta@oracle.com> To: Al Brown/Costa Mesa/IBM@IBMUS Cc: James M Snell <jasnell@gmail.com>, atom-syntax Syntax <atom-syntax@imc.org> Date: 06/08/2009 03:33 PM Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-01 As I see it, whether there is a @rel=down-tree or not, you would have to communicate certain information out-of-band, e.g., depth of the tree or the level of completeness in every in-lined entry. Atom does not provide any means of advertising URIs for retrieving representation variants. This could be a source of your dissatisfaction but it applies equally well regardless of hierarchy or in-lining. On Jun 8, 2009, at 3:11 PM, Al Brown wrote: James wrote: >Hmmm.... I know we've discussed this, but after thinking about it more >and looking through the examples, I'm becoming increasingly less >convinced that we need a distinction between "down" and "down-tree". >One should simply assume that "down" could point to a child entry or >child feed and that those children could potentially also be parents. >Yes, that possibly increases the processing compexity but I think it >simplifies the model overall. We've discussed this today on the phone. For me this is a difference of protocol/hypermedia vs. syntax. For syntax, "down" and "up" are sufficient. A flat model can modeled with feed and a tree can be modeled using generic inlining in a feed or entry. A client requests an atom document - entry or feed. How does the server advertise to the client, via what is in the atom document, here are two links to representations (flat vs. tree) of a resource, e.g. the folder's children: one link returns a flat list (no inlining) and one link returns a tree (inlined). It is no different from seeing an HTML vs. a PDF representation of the same blog entry. One gives you a lot of context such as comments, related posts, advertisements and the like, and the other may be limited. This problem, AFAICT, exists regardless of CMIS or hierarchy. Both are the same document just with or without inlining of linked resources of a particular link relation. For all practical purposes, they are different documents, i.e., different representations of a single resource. Since the resources are crossing the wire, the first resource (e.g., folder) needs to convey how access a hierarchical resource (e.g., items in a folder) in either a flat mode (feed) or tree (feed with inlined resources). The options I see are: a. append -tree to link relations that may inline (e.g., down-tree, up-tree). Not so nice, but works. It may not be specific enough anyway to say this is a tree link because it says nothing about depth b. add a new attribute to link that specifies if they are inlined (down) <link rel="down" href="http://www.example.com/foo/down" /> (down-tree) <link rel="down" ah:inlined="true" href=" http://www.example.com/foo/down/inlined" /> This adds complexity if there are cardinality constraints on link relations such as alternate and clients not aware of I-D may think they are the same. IMHO, ah:inlined does nothing because the presence of ae:inline makes it plenty clear. If you were trying to say that there is a certain level of depth in the tree, may be an attribute would help, but even then you don't know what things the server may have elided from every entry. So, bottom line is, there is not much value to an attribute to describe the thing that is in-lined. You are best off using what you have received as an approximation and then get the exact representation if you care so much in a separate network call. Of course, out-of-band communication or specialized mark-up may provide enough information for you to avoid such round-trips. c. leverage link templates rather than link relations I am not aware of "link templates". If you are referring to draft-gregorio-uri-templates, then too there is no notion of templates baked in to the link element yet. d. use out of band communication - append a uri argument such as includeLinkRel=down to the URI of the resource; could also be HTTP header. Not very RESTful but works. If the model is not sufficient to convey to the client here's a flat mode vs. here's a tree mode, CMIS will have to find another alternative as it is currently required by the CMIS domain model. I see the options for CMIS as: 1. Leverage the model specified by the I-D if exists (best) 2. Move down-tree to CMIS namespace. This does not solve the protocol/hypermedia problem for anybody else. 3. Specify in the CMIS specification an URI argument to enable inlining of 'down'. -Al Al Brown Emerging Standards and Industry Frameworks CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email albertcbrown@us.ibm.com CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of the person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify the sender. Please also permanently delete all copies of the original message and any attached documentation. <graycol.gif>James M Snell ---06/08/2009 11:55:37 AM---Comments below... <ecblan <ecblank.gif> k.gif> James M Snell <jasnell@gmail.com> From: <ecblan <ecblank.gif> k.gif> Al Brown/Costa Mesa/IBM@IBMUS To: <ecblan <ecblank.gif> k.gif> "Nikunj R. Mehta" <nikunj.mehta@oracle.com>, Atom-Syntax Syntax < Cc: atom-syntax@imc.org>, owner-atom-syntax@mail.imc.org <ecblan <ecblank.gif> k.gif> 06/08/2009 11:55 AM Date: <ecblan <ecblank.gif> k.gif> Re: Fwd: New Version Notification for Subject draft-divilly-atom-hierarchy-01 : Comments below... Al Brown wrote: > > The 01 draft is a much better. I am concerned the generic mechanism > using inlining links is sub-optimal for displaying a hierarchy that > this I-D helps navigate via the new link relations. > in-lining arbitrarily complex hierarchies is always going to be problematic and suboptimal... which is why I was so adamant about not baking hierarchy into Atom and Atompub in the first place when we were working on all this stuff initially. Despite the added verbosity that this approach adds, however, I think it's likely the most acceptable approach. > First example: there are two down relations: down and down-tree. It is > important to have both of those link relations on the [standalone] > atom entry that represents a folder so the client can chose a flat > (feed) or tree (expanded feed) representation. If the client chooses > the tree representation, then on the atom feed returned the server > will inline using the link relation down. down-tree is not expanded > with content inline. E.g., > > <atom:entry> > ... > <!-- children level 1 --> > <atom:link rel="down" type="application/atom+xml;type=feed" > href="/finance/feeds/default/portfolios/1/positions"> > <ae:inline> > <atom:feed> > <!-- /a --> > <atom:entry> > ... > <!-- children level 2 for /a --> > <atom:link rel="down" > href="/finance/feeds/default/portfolios/1/positions"/> > ... > <ae:inline> > <atom:feed> > <!-- entry /a/1 --> > <atom:entry> > ... > <atom:link rel="down" > href="/finance/feeds/default/portfolios/1/positions/down"> > <!-- repeats --> > </atom:link> > <atom:link rel="down-tree" > href="/finance/feeds-tree/default/portfolios/1/positions/down" /> > > ... > </atom:entry> > </atom:feed> > </ae:inline> > <atom:entry>...</atom:entry> > <atom:entry>...</atom:entry> > </atom:feed> > </ae:inline> > </atom:link> > <atom:link rel="down-tree" type="application/atom+xml;type=feed" > href="/finance/feeds-tree/default/portfolios/1/positions" /> > > ... > </atom:entry> > > The contents of the down link relation will be what should be included > in the down-tree due to recursion through the atom entries. Having a > separate extension element, side-steps this issue of expression. > Hmmm.... I know we've discussed this, but after thinking about it more and looking through the examples, I'm becoming increasingly less convinced that we need a distinction between "down" and "down-tree". One should simply assume that "down" could point to a child entry or child feed and that those children could potentially also be parents. Yes, that possibly increases the processing compexity but I think it simplifies the model overall. > Second example: verbosity > This proposal now has: > <atom:entry> > ... > <atom:link rel="down" type="application/atom+xml;type=feed" > href="/finance/feeds/default/portfolios/1/positions"> > <ae:inline> > <atom:feed> > <atom:link rel="self" > href="/finance/feeds/default/portfolios/1/positions"/> > ... > <atom:entry>...</atom:entry> > <atom:entry>...</atom:entry> > <atom:entry>...</atom:entry> > </atom:feed> > </ae:inline> > </atom:link> > ... > </atom:entry> > > instead of a simpler mechanism: > <atom:entry> > ... > <ah:include rel="down"> > <atom:entry>...</atom:entry> > <atom:entry>...</atom:entry> > <atom:entry>...</atom:entry> > </ah:include> > ... > </atom:entry> > > The I-D introduces a concept of hierarchy through > up/up-tree/down-tree/down relations yet a all-purpose mechanism for > inclusion. Most (all?) of the information on the feed element is > duplicated on the enclosing entry (id, uri, etc). Can't we do better > for this specific scenario the I-D is addressing? > I think we can address this by eliminating the restriction that "down" and "up" must always point to Atom feed documents and by changing the cardinality rules for those links. That restriction, I think, is arbitrary and unnecessary It would allow us to do something like.... <atom:entry> ... <atom:link rel="down" type="application/atom+xml;type=entry" href="child1"> <ae:inline> <atom:entry>...</atom:entry> </ae:inline> </atom:link> <atom:link rel="down" type="application/atom+xml;type=entry" href="child2"> <ae:inline> <atom:entry>...</atom:entry> </ae:inline> </atom:link> ... <atom:link rel="down" type="application/atom+xml;type=entry" href="childN"> <ae:inline> <atom:entry>...</atom:entry> </ae:inline> </atom:link> ... </atom:entry> Unlike any of the other methods discussed, this approach would allow clients that don't understand the hierarchy model to still understand that there is some kind of link relationship with each of the individual child resources and eliminates the need to include the extraneous atom:feed metadata. Note that this is the same basic approach taken by my comment thread extension (in-reply-to). - James
- Fwd: New Version Notification for draft-divilly-a… Nikunj R. Mehta
- Re: Fwd: New Version Notification for draft-divil… Al Brown
- Re: Fwd: New Version Notification for draft-divil… James M Snell
- Re: New Version Notification for draft-divilly-at… Nikunj R. Mehta
- Re: New Version Notification for draft-divilly-at… Al Brown
- Re: Fwd: New Version Notification for draft-divil… Hadrien Gardeur
- Re: New Version Notification for draft-divilly-at… James M Snell
- Re: Fwd: New Version Notification for draft-divil… James M Snell
- Re: New Version Notification for draft-divilly-at… Nikunj R. Mehta
- Re: New Version Notification for draft-divilly-at… Nikunj R. Mehta
- Re: New Version Notification for draft-divilly-at… James M Snell
- Re: Fwd: New Version Notification for draft-divil… Al Brown
- Re: New Version Notification for draft-divilly-at… Nikunj R. Mehta
- Re: New Version Notification for draft-divilly-at… James M Snell
- Re: New Version Notification for draft-divilly-at… Al Brown
- Re: New Version Notification for draft-divilly-at… James M Snell
- Re: New Version Notification for draft-divilly-at… Nikunj R. Mehta
- Re: New Version Notification for draft-divilly-at… James M Snell
- Re: New Version Notification for draft-divilly-at… Bjoern Hoehrmann
- Re: New Version Notification for draft-divilly-at… Al Brown
- Re: New Version Notification for draft-divilly-at… Nikunj R. Mehta
- Re: New Version Notification for draft-divilly-at… jasnell
- Re: New Version Notification for draft-divilly-at… Nikunj R. Mehta
- Re: New Version Notification for draft-divilly-at… Peter Keane