Subject: Fwd: New Version Notification for draft-divilly-atom-hierarchy-02

From: "Nikunj R. Mehta" <[email-masked]>
Date: Wed, 10 Jun 2009 09:58:15 -0700

Based on feedback, I have simplified the I-D to:
In-line extensions moved to draft-mehta-atom-inline
       Removed down-tree and up-tree relations
       Removed cardinality restrictions on up and down links

HTML: http://tools.ietf.org/html/draft-divilly-atom-hierarchy-02
Text: http://tools.ietf.org/id/draft-divilly-atom-hierarchy-02.txt
Diff: http://tools.ietf.org/rfcdiff?url2=draft-divilly-atom-hierarchy-02.txt

I am also tracking open issues about this I-D publicly at http://code.google.com/p/atom-ext/issues/list 
. The source for this I-D is also available, if you are interested.

Looking forward to comments on the I-D.

Nikunj
http://o-micron.blogspot.com

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: June 9, 2009 5:33:57 PM PDT
> To: [email-masked]
> Cc: [email-masked]
> Subject: New Version Notification for draft-divilly-atom-hierarchy-02
>
>
> A new version of I-D, draft-divilly-atom-hierarchy-02.txt has been  
> successfuly submitted by Nikunj Mehta and posted to the IETF  
> repository.
>
> Filename:	 draft-divilly-atom-hierarchy
> Revision:	 02
> Title:		 Hierarchy Relations for Atom
> Creation_date:	 2009-06-09
> WG ID:		 Independent Submission
> Number_of_pages: 7
>
> Abstract:
> This specification defines link relations for hierarchical navigation
> among Atom feeds and entries.Editorial Note
>
> To provide feedback on this Internet-Draft, join the atom-syntax
> mailing list (http://www.imc.org/atom-syntax/) [1].
>
>
>
> The IETF Secretariat.
>
>

---

From: James M Snell <[email-masked]>
Date: Wed, 10 Jun 2009 10:55:59 -0700

Thank you for the changes. Another issue that needs to be looked at 
(which existing in the previous version of the draft as well) is how a 
processor can reconstruct the logical set of children for an entry... 
that is, for instance, if the set of child entries contains multiple 
atom:entry elements with the same atom:id value, are those viewed as 
separate children or is only the entry with the most recent atom:updated 
value included in the set of children? Further, if multiple "down" links 
are specified, each pointing to separate Atom feeds with separate 
entries with distinct atom:id values, is that to be viewed as two 
separate child collections or a single logical combined collection? I 
would recommend the latter.

Nikunj R. Mehta wrote:
> <http://tools.ietf.org/id/draft-mehta-atom-inline-00.txt>
> I 
> am also tracking open issues about this I-D publicly at http://code.google.com/p/atom-ext/issues/list. 
> The source for this I-D is also available, if you are interested.
>
> http://o-micron.blogspot.com <http://o-micron.blogspot.com/>
>
>
> Begin forwarded message:
>
>> *From: *IETF I-D Submission Tool <[email-masked] 
>> <mailto:[email-masked]>>
>> *Date: *June 9, 2009 5:33:57 PM PDT
>> *To: [email-masked] <mailto:[email-masked]>
>> *Cc: [email-masked] <mailto:[email-masked]>
>> *Subject: **New Version Notification for 
>> draft-divilly-atom-hierarchy-02 *
>>
>>
>> successfuly submitted by Nikunj Mehta and posted to the IETF repository.
>>

---

From: "Nikunj R. Mehta" <[email-masked]>
Date: Wed, 10 Jun 2009 11:15:04 -0700

On Jun 10, 2009, at 10:55 AM, James M Snell wrote:

> (which existing in the previous version of the draft as well)

This issue did not exist in the previous draft since only one link  
with @rel value down and @type application/atom+xml was possible.

> is how a processor can reconstruct the logical set of children for  
> an entry... that is, for instance, if the set of child entries  
> contains multiple atom:entry elements with the same atom:id value,  
> are those viewed as separate children or is only the entry with the  
> most recent atom:updated value included in the set of children?

We have two choices - either constrain cardinality and obtain an  
unambiguous logical set of children or remove the cardinality  
constraint and leave it to applications to interpret multiple sets or  
subsets. I don;t see how we can get a third option. BTW, the threading  
extension uses the second approach and §2.2 as well as §2.3 of  
hierarchy I-D explain what an Atom processor does with multiple  
occurrences of the down and up link, respectively.

> Further, if multiple "down" links are specified, each pointing to  
> separate Atom feeds with separate entries with distinct atom:id  
> values, is that to be viewed as two separate child collections or a  
> single logical combined collection? I would recommend the latter.

As I explain above, this choice is infeasible. How is one to reconcile  
an HTML linked resource with an entry with a feed and an image all  
through @rel=down? I would be interested in learning of a proposal to  
handle this kind of a situation.

>> Text: http://tools.ietf.org/id/draft-divilly-atom-hierarchy-02.txt <http://tools.ietf.org/id/draft-mehta-atom-inline-00.txt 
>> >
>>> *From: *IETF I-D Submission Tool <[email-masked] <mailto:[email-masked] 
>>> >>
>>> *Subject: **New Version Notification for draft-divilly-atom- 
>>> hierarchy-02 *
>>>
>>>

---

From: [email-masked]
Date: Wed, 10 Jun 2009 18:29:13 +0000

Yes, the issue did exist before given that the linked atom feed could easily have multiple atom:entry elements with the same atom:id value as allowed by rfc4287. It is a simple matter to answer whether there can be multiple distict child sets or a single logical child set and to answer whether membership in that set is based on instance or identity. 

- James  
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: "Nikunj R. Mehta" <[email-masked]>

Date: Wed, 10 Jun 2009 11:15:04 
To: James M Snell<[email-masked]>
Cc: atom-syntax Syntax<[email-masked]>
Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-02

---

From: Hadrien Gardeur <[email-masked]>
Date: Wed, 10 Jun 2009 22:36:15 +0200

I'd like to see some recommendations concerning thr:count, now that ah:count
isn't in the I-D anymore.
Maybe something like:
"A link@rel="down" MAY indicate the number of child elements through
thr:count [RFC4685]. Atom clients can use this information to decide if they
need to GET the entry."
And remind this too: http://tools.ietf.org/html/rfc4685#section-6

<http://tools.ietf.org/html/rfc4685#section-6>Hadrien

---

From: [email-masked]
Date: Thu, 11 Jun 2009 00:47:32 -0400

I ask your forgiveness for rehashing an old (a few days old) topic - the
suggestion that James Snell made for using a media-type profile to
distinguish between an entry's children and an entry's descendants.  I
think I get it but want to run this by the group for confirmation.

In the following (from James):

> <link rel="down" type="application/atom+xml;type=feed;profile=tree"
href="..." /> <link rel="down"
type="application/atom+xml;type=feed;profile=flat" href="..." /> 

a value of profile=flat is used to indicate that we want the children to
be represented without any expansion and a value of profile=tree is used
to indicate that we want the children to be represented with a potential
expansion.  I confess that initially I thought that this wasn't a
mimetype issue, that we were talking about two different resources - the
set of children and the set of descendants.  But  what is proposed here
is far more elegant, and is nicely cast as a mime-type choice.  The key
is that the link relation "down" only ever returns a child (as
application/atom+xml;type=entry) or a feed containing _only children_
(as application/atom+xml;type=feed) - what differs is the representation
format of that child (expanded or not).

Sound right?

And yes, I understand that the mime types and profile designators are
most definitely outside the scope of this I-D.

Thanks,

Cornelia

Cornelia Davis

Senior Technologist

EMC Corporation, Office of the CTO
[email-masked]
p: 805.560.9039
m: 805.452.8941
f: 805.880.0390

________________________________

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nikunj R. Mehta
Sent: Wednesday, June 10, 2009 9:58 AM
To: atom-syntax Syntax
Subject: Fwd: New Version Notification for
draft-divilly-atom-hierarchy-02 

Diff:
http://tools.ietf.org/rfcdiff?url2=draft-divilly-atom-hierarchy-02.txt

I am also tracking open issues about this I-D publicly at
http://code.google.com/p/atom-ext/issues/list. The source for this I-D
is also available, if you are interested.

Nikunj

 

Begin forwarded message:

Abstract:

The IETF Secretariat.

---

From: [email-masked]
Date: Thu, 11 Jun 2009 15:41:58 +0000

Yes your interpretation is correct. 
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: [email-masked]

Date: Thu, 11 Jun 2009 00:47:32 
To: <[email-masked]>; <[email-masked]>
Subject: RE: New Version Notification for draft-divilly-atom-hierarchy-02 

application/atom+xml;type=entry) or a feed containing_only children_

Sound right?

Thanks,

Cornelia

Cornelia Davis

Senior Technologist

Diff:

Nikunj

 

Begin forwarded message:

Abstract:

The IETF Secretariat.

---

From: "Nikunj R. Mehta" <[email-masked]>
Date: Thu, 11 Jun 2009 12:25:49 -0700

On Jun 10, 2009, at 9:47 PM, [email-masked] wrote:

>  I confess that initially I thought that this wasn’t a mimetype  
> issue, that we were talking about two different resources – the set  
> of children and the set of descendants.  But  what is proposed here  
> is far more elegant, and is nicely cast as a mime-type choice.  The  
> key is that the link relation “down” only ever returns a child (as  
> application/atom+xml;type=entry) or a feed containing _only  
> children_ (as application/atom+xml;type=feed) – what differs is the  
> representation format of that child (expanded or not).

Actually, atom-hierarchy-02 allows link@rel=down with other non-Atom  
@type values too. Not only that, presently a combination of @type  
values can be used in a single entry with link@rel=down, including  
Atom content type.

Is that overly flexible? That is the currently open question.

Nikunj

---

From: "Nikunj R. Mehta" <[email-masked]>
Date: Thu, 11 Jun 2009 12:29:21 -0700

On Jun 10, 2009, at 1:36 PM, Hadrien Gardeur wrote:

> I'd like to see some recommendations concerning thr:count, now that  
> ah:count isn't in the I-D anymore.
>
> Maybe something like:
> thr:count [RFC4685]. Atom clients can use this information to decide  
> if they need to GET the entry."

This is certainly doable. In case you are interested, you can track it  
[1].

Nikunj

[1] http://code.google.com/p/atom-ext/issues/detail?id=1

---

From: "Nikunj R. Mehta" <[email-masked]>
Date: Thu, 11 Jun 2009 12:41:41 -0700

On Jun 10, 2009, at 11:29 AM, [email-masked] wrote:

> Yes, the issue did exist before given that the linked atom feed  
> could easily have multiple atom:entry elements with the same atom:id  
> value as allowed by rfc4287. It is a simple matter to answer whether  
> there can be multiple distict child sets or a single logical child  
> set and to answer whether membership in that set is based on  
> instance or identity.
>

I see what you are saying. Perhaps we can just follow RFC4287 and say  
that the entry with the latest atom:updated wins. In that sense,  
membership in the logical child set is based on instance. [1]

>> most recent atom:updated value included in the set of children?

[1] http://code.google.com/p/atom-ext/issues/detail?id=4