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

From: "Nikunj R. Mehta" <[email-masked]>
Date: Wed, 20 May 2009 10:08:42 -0700

Based on feedback received on this and the atom-protocol list as well  
as others interested in hierarchical relations in Atom, we have split  
out the hierarchical navigation and representation portions from the  
draft-divilly-atompub-hierarchy-00. This was done with the intention  
of achieving consensus on the Atom syntax to be used for parent/child  
like navigation separately from how such resources are manipulated.

We look forward to the feedback of this community and will continue to  
edit the I-D to incorporate the feedback. Here are links to the I-D:

Text: http://www.ietf.org/internet-drafts/draft-divilly-atom-hierarchy-00.txt
HTML: http://www.oracle.com/technology/tech/feeds/spec/draft-divilly-atom-hierarchy.html

Regards,
Nikunj

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: May 20, 2009 9:54:15 AM PDT
> To: [email-masked]
> Cc: [email-masked]
> Subject: New Version Notification for draft-divilly-atom-hierarchy-00
>
>
> A new version of I-D, draft-divilly-atom-hierarchy-00.txt has been  
> successfuly submitted by Nikunj Mehta and posted to the IETF  
> repository.
>
> Filename:	 draft-divilly-atom-hierarchy
> Revision:	 00
> Title:		 Hierarchy Extensions for Atom
> Creation_date:	 2009-05-20
> WG ID:		 Independent Submission
> Number_of_pages: 10
>
> Abstract:
> This specification defines mechanisms 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.
>
>

Nikunj R Mehta | Consulting Member of Technical Staff | Phone: +1 650  
506 0679 | Blog: http://o-micron.blogspot.com
Oracle Advanced Development Projects
500 Oracle Parkway #4OP662 | Redwood Shores, CA 94065
  Oracle is committed to developing practices and products that help  
protect the environment

---

From: Peter Keane <[email-masked]>
Date: Wed, 20 May 2009 13:24:32 -0500

Hi Nikunj-

Very nice work.  I have a couple of questions:

Can an entry contain more than one child feed (i.e. down link) of
different types?  (I assume not per atom:link@rel="down" (1..1)
cardinality constraint).  In that case, would the entry have a child
feed that itself would contain parent entries, one for each feed of
varying type:

parent entry
-- child feed
-- -- parent entry
-- -- -- child feed type a
-- -- parent entry
-- -- -- child feed type b

Also, looks like IANA Atom Link registry already includes "up."  This
ID is simply reusing that, correct?

--peter

On Wed, May 20, 2009 at 12:08 PM, Nikunj R. Mehta
<[email-masked]> wrote:
> Based on feedback received on this and the atom-protocol list as well as
> others interested in hierarchical relations in Atom, we have split out the
> hierarchical navigation and representation portions from
> the draft-divilly-atompub-hierarchy-00. This was done with the intention of
> achieving consensus on the Atom syntax to be used for parent/child like
> navigation separately from how such resources are manipulated.
> We look forward to the feedback of this community and will continue to edit
> the I-D to incorporate the feedback. Here are links to the I-D:
> successfuly submitted by Nikunj Mehta and posted to the IETF repository.
>
> Nikunj R Mehta | Consulting Member of Technical Staff | Phone: +1 650 506
> 0679 | Blog: http://o-micron.blogspot.com
>  Oracle is committed to developing practices and products that help protect
> the environment
>

---

From: "Nikunj R. Mehta" <[email-masked]>
Date: Wed, 20 May 2009 11:36:36 -0700

Actually, if there is enough support, there is a much better way out  
as blogged earlier [1]. Of course, that is not currently included in  
the hierarchy I-D [2], but that can change.

Atom syntax places no limits on the multiple occurrence of link@rel  
within a single entry or feed, except for a few relations defined in  
RFC 4287. Also, I could technically use the term attribute previously  
defined in the atom namespace to differentiate between the several  
child feeds.

An example to illustrate my point:

<entry xmlns="..." xmlns:ah=".../">
   <title>A folder entry</title>
   ...
   <content src="..."/>
   <link rel="self" href="/folder;metadata"/>

   <link rel="down" type="application/atom+xml;type=feed"
       title="Folder children collection"
       href="/folder;contents/" term="contents" ah:count="0"/>
   <link rel="down" type="application/atom+xml;type=feed"
       title="Folder relationships collection"
       href="/folder;relationships/" term ="relationships"  
ah:count="0"/>
   <link rel="related" type="application/atom+xml;type=feed"
       title="Folder descendants feed"
       href="/folder;descendants/" term ="descendants" ah:count="0"/>
   <link rel="detail" type="application/atom+xml;type=feed"
       title="Folder policy collection"
       href="/folder;policies/" term ="policies" ah:count="0"/>
</entry>

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

[1] http://o-micron.blogspot.com/2009/05/atom-multiple-links-with-same-rel-value.html
[2] http://www.ietf.org/internet-drafts/draft-divilly-atom-hierarchy-00.txt

On May 20, 2009, at 11:24 AM, Peter Keane wrote:

>> protect

---

From: "Nikunj R. Mehta" <[email-masked]>
Date: Wed, 20 May 2009 11:37:27 -0700

> ID is simply reusing that, correct?

That is correct.

Nikunj Mehta

---

From: Julian Reschke <[email-masked]>
Date: Mon, 25 May 2009 17:35:00 +0200

>> ID is simply reusing that, correct?

And a good thing; that being said we should make that explicit in the 
IANA Considerations Section.

In addition, it would be good to rephrase "Description:" part of these 
so that they become generic, and not tied to Atom.

And, as a nit, the "Security considerations:" shouldn't say "this 
draft", as it won't be a draft anymore when it gets published :-).

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 25 May 2009 17:42:42 +0200

Nikunj R. Mehta wrote:
> others interested in hierarchical relations in Atom, we have split out 
> the hierarchical navigation and representation portions from 
> the draft-divilly-atompub-hierarchy-00. This was done with the intention 

Ni Nikunj,

with respect to 
<http://tools.ietf.org/html/draft-divilly-atom-hierarchy-00#section-3>, 
"Inline Representation of Hierarchical Resources"...

It seems to be that using atom:link as a container elements stretches 
its semantics of "reference from an entry or feed to a Web resource" too 
much.

As Al pointed out on the CMIS mailing list 
(<http://lists.oasis-open.org/archives/cmis/200905/msg00186.html>), it 
may be better to use a container element inside atom:entry.

So, the example in 
<http://tools.ietf.org/html/draft-divilly-atom-hierarchy-00#section-3.2.3>:

    <atom:entry>
      <atom:link rel="down"
        href="/finance/feeds/default/portfolios/1/positions">
        <atom:feed>
          <atom:link rel="self"
           href="/finance/feeds/default/portfolios/1/positions"/>
           ...
        </atom:feed>
      </atom:link>
      ...
    </atom:entry>

would become

    <atom:entry>
      <atom:link rel="down"
        href="/finance/feeds/default/portfolios/1/positions" />
      <ah:children>
        <atom:feed>
          <atom:link rel="self"
           href="/finance/feeds/default/portfolios/1/positions"/>
           ...
        </atom:feed>
      </ah:children>
      ...
    </atom:entry>

BR, Julian

---

From: "Nikunj R. Mehta" <[email-masked]>
Date: Tue, 26 May 2009 13:59:20 -0700

On May 25, 2009, at 8:35 AM, Julian Reschke wrote:

> And a good thing; that being said we should make that explicit in  
> the IANA Considerations Section.

Will do. This will be included in atom-hierarchy--01

>
>
> In addition, it would be good to rephrase "Description:" part of  
> these so that they become generic, and not tied to Atom.

Will do. This will be included in atom-hierarchy--01
> draft", as it won't be a draft anymore when it gets published :-).

Will do. This will be included in atom-hierarchy--01

---

From: "Nikunj R. Mehta" <[email-masked]>
Date: Tue, 26 May 2009 14:07:27 -0700

On May 25, 2009, at 8:42 AM, Julian Reschke wrote:

> with respect to <http://tools.ietf.org/html/draft-divilly-atom-hierarchy-00#section-3 
> >, "Inline Representation of Hierarchical Resources"...
>
> It seems to be that using atom:link as a container elements  
> stretches its semantics of "reference from an entry or feed to a Web  
> resource" too much.

I don't agree with that. A previous discussion on this mailing list  
more than a year ago [1] has already concluded that it is perfectly  
legal to do so. Additionally, the hierarchy-ID approach appears  
similar to the approach taken by the RFC4287 with atom:content usage  
models, where several options about inline and out-of-line content  
delivery are available.

>
>
> As Al pointed out on the CMIS mailing list (<http://lists.oasis-open.org/archives/cmis/200905/msg00186.html 
> >), it may be better to use a container element inside atom:entry.
>
> So, the example in <http://tools.ietf.org/html/draft-divilly-atom-hierarchy-00#section-3.2.3 
> >:
>
>   <atom:entry>
>     <atom:link rel="down"

Nikunj

[1] http://www.imc.org/atom-syntax/mail-archive/msg20464.html

---

From: Julian Reschke <[email-masked]>
Date: Wed, 27 May 2009 14:12:54 +0200

Nikunj R. Mehta wrote:
>> its semantics of "reference from an entry or feed to a Web resource" 
>> too much.
> 
> I don't agree with that. A previous discussion on this mailing list more 
> than a year ago [1] has already concluded that it is perfectly legal to 
> do so. Additionally, the hierarchy-ID approach appears similar to the 

I do not agree with that conclusion, but nevertheless, just because 
something is syntactically legal doesn't make it a good choice.

atom:link is defined to as:

   "The "atom:link" element defines a reference from an entry or feed to 
a Web resource."

Inlining the content of referenced web resource is IMHO contrary to that 
definition.

> approach taken by the RFC4287 with atom:content usage models, where 
> several options about inline and out-of-line content delivery are 
> available.

But atom:content has been explicitly designed that way:

   "The "atom:content" element either contains or links to the content 
of the entry." -- 
<http://greenbytes.de/tech/webdav/rfc4287.html#rfc.section.4.1.3>

while atom:link has not.

So I'll stick with my comment that atom:entry is better suited for that 
purpose, being defined as:

    "The "atom:entry" element represents an individual entry, acting as 
a container for metadata and data associated with the entry." -- 
<http://greenbytes.de/tech/webdav/rfc4287.html#rfc.section.4.1.2>

>>          href="/finance/feeds/default/portfolios/1/positions"/>

BTW: the format above is currently forbidden by the RNC (because of the 
use of the atom namespace for the contained element); I know that part 
of the spec is informative, but still...

BR, Julian

---

From: "Nikunj R. Mehta" <[email-masked]>
Date: Thu, 28 May 2009 11:56:09 -0700

There is precedence to the proposal I have submitted. GData uses  
feedLink [1] and entryLink [2] mechanisms in Google's own namespace to  
include in-line representations of entries and feeds. Notice how these  
elements have both @rel and @href, critical to the functioning of  
Atom's own link mechanisms.

The atom-hierarchy-ID is merely trying to standardize such behavior  
and not invent new behavior. Moreover, the proposed syntax is not  
merely syntactically legal, it is also semantically valuable. There  
are three benefits to this approach:

1. The context of the inlined feed or entry is immediately clear from  
the @rel value
2. The server can choose to inline content as per requirements and  
configuration
3. The format supports inlining of any number of entries - a single or  
multiple. It also expresses the absence of any entries, when this is  
required.

Which of these advantages can you claim for directly embedding an  
entry inside another?

Nikunj

On May 27, 2009, at 5:12 AM, Julian Reschke wrote:

>>> stretches its semantics of "reference from an entry or feed to a  
>>> Web resource" too much.
>> similar to the
>  "The "atom:link" element defines a reference from an entry or feed  
> to a Web resource."
>
> Inlining the content of referenced web resource is IMHO contrary to  
> that definition.
>
> of the entry." -- <http://greenbytes.de/tech/webdav/rfc4287.html#rfc.section.4.1.3 
> >
>
> while atom:link has not.

I respectfully disagree although you are entitled to your opinion.  
Previous discussion on this mailing list [3], which included several  
people who were part of the early crowd of atom-syntax, has made it  
clear that one should not go by any prejudice about the lack of  
specification of a certain previously undefined mark up usage.

>
>
> So I'll stick with my comment that atom:entry is better suited for  
> that purpose, being defined as:
>
>   "The "atom:entry" element represents an individual entry, acting  
> as a container for metadata and data associated with the entry." -- <http://greenbytes.de/tech/webdav/rfc4287.html#rfc.section.4.1.2 
> >
>
>
> BTW: the format above is currently forbidden by the RNC (because of  
> the use of the atom namespace for the contained element); I know  
> that part of the spec is informative, but still...
>

Again, you are misleading the reader to assume that RNC schema is  
normative. There is a very good reason for it to not be normative and  
the spec editors were clear about them.

Nikunj

[1] http://code.google.com/apis/gdata/elements.html#gdFeedLink
[2] http://code.google.com/apis/gdata/elements.html#gdEntryLink
[3] http://www.imc.org/atom-syntax/mail-archive/msg20456.html