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.
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.
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?
Also,
Are there reasons for the statements below? A resource may be involved in
many different independent hierarchies - e.g., folder structure, file plan,
etc. Most of which we probably cannot imagine right now, but may be used
in a year or two. This also conflicts with the current 'up' relation
which, as not stated otherwise, allows multiple 'up' link relations in a
single entry or feed.
Section 4.1:[1]
>An entry MUST NOT contain more than one atom:link element with a rel
attribute value of "down" that has the same combination of type and
>hreflang attribute values.
Section 4.2:
>An entry MUST NOT contain more than one atom:link element with a rel
attribute value of "down-tree" that has the same combination of type and
>hreflang attribute values.
Section 5.1:
>A feed MUST NOT contain more than one atom:link element with a rel
attribute value of "up" that has the same combination of type and hreflang
>attribute values.
Section 5.2:
>An entry MUST NOT contain more than one atom:link element with a rel
attribute value of "up-tree" that has the same combination of type and
>hreflang attribute values.
-Al
[1]
http://www.oracle.com/technology/tech/feeds/spec/draft-divilly-atom-hierarchy.html
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 [email protected]
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" <[email protected]>
To: Atom-Syntax Syntax <[email protected]>
Date: 06/05/2009 11:18 AM
Subject: Fwd: New Version Notification for draft-divilly-atom-hierarchy-01
All the feedback on this mailing list has been really useful. We have
revised the I-D to reflect the thinking about in-lining inside atom:link
using foreign markup. We've also made the use of in-line representations
independent of the the new link relations. Looking forward to comments and
implementation experience.
01 - Changes include:
In-line representations of linked resources are independent of
hierarchy
Removed Atom specific language in link relation definitions
Made explicit that this specification re-uses existing 'up'
link relation
Changed namespace prefix from ah to ae
Removed the ah:count attribute and added the ae:inline element
Text:
http://www.ietf.org/internet-drafts/draft-divilly-atom-hierarchy-01.txt
HTML:
http://www.oracle.com/technology/tech/feeds/spec/draft-divilly-atom-hierarchy.html
Nikunj
http://o-micron.blogspot.com
Begin forwarded message:
From: IETF I-D Submission Tool <[email protected]>
Date: June 5, 2009 10:06:45 AM PDT
To: [email protected]
Cc: [email protected]
Subject: New Version Notification for draft-divilly-atom-hierarchy-01
A new version of I-D, draft-divilly-atom-hierarchy-01.txt has been
successfuly submitted by Nikunj Mehta and posted to the IETF
repository.
Filename: draft-divilly-atom-hierarchy
Revision: 01
Title: Inlining and Hierarchy Extensions for Atom
Creation_date: 2009-06-05
WG ID: Independent Submission
Number_of_pages: 11
Abstract:
This specification defines mechanisms for in-lining representations
of linked resources and 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.
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
