On Jun 5, 2009, at 2:06 PM, 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.
I read "displaying" as conveying, since Atom format is all about a
representation, and not a rendering.
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.
With you so far.
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.,
When producing an entry representation, e.g., for a folder, the server
may go one level deep by in-lining the "down" relation but not in-
lining the entries in the already in-lined link. Or it can choose to
arbitrarily in-line linked resources. The communication between the
client and the server about what representation is desirable may
either be out of band, or be a part of the request (either through
query parameters or custom headers)
<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>
I can't make sense of this example since it appears to be not well-
formed XML (omitting ellipsis). Can you, perhaps, retry with a well-
formed example? Also, your concern is not clear (to me).
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.
Is this related to your concerns about duplication [1]. If so, let me
say that a server can choose to in-line where it finds the need to and
not, where it doesn't. In fact, it may be possible to get rid of the
down-tree relation, if the representation of "down" can be in-lined to
a suitable depth. That may actually be preferable anyway.
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).
If verbosity is a concern, then the fact that we repeat the text
"atom:entry" about 8 times in the above example is a valid target.
However, that is besides the point. Even if we were to take the
"simpler mechanism", you would still have to put in id, title,
updated, etc. because the definition of atom:entry requires those
things. See Section 4.1.2 of RFC 4287. BTW, link is not one of the
required elements in a valid entry, so you could skip it in either case.
Can't we do better for this specific scenario the I-D is addressing?
Yes, the server can avoid sending anything in the in-lined entry that
is not required for being treated as valid Atom by RFC 4287. This is
unrelated to the hierarchy I-D.
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.
RFC 4287 already defines a similar constraint for @rel="alternate".
RFC 4287 provides two discriminators for link elements in addition to
rel, and processors use this to select one that is suitable for the
purpose, and these are type and hreflang. Since down defines a formal
relation between the referrer and the referee, it is necessary to have
a clear meaning for multiple occurrences of that relation. Therefore
the text above. If you can propose an alternate resolution of the
issue I identified just now, I'll be interested in reviewing it.
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.
<graycol.gif>"Nikunj R. Mehta" ---06/05/2009 11:18:07 AM---All the
feedback on this mailing list has been really useful. We have
revised the I-D to reflect the thinking about in-lining i
<ecblank.gif>
From: <ecblank.gif>
"Nikunj R. Mehta" <[email protected]>
<ecblank.gif>
To: <ecblank.gif>
Atom-Syntax Syntax <[email protected]>
<ecblank.gif>
Date: <ecblank.gif>
06/05/2009 11:18 AM
<ecblank.gif>
Subject: <ecblank.gif>
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.
