[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: Hierarchy ID draft Al Brown Wed May 27 09:01:52 2009

No worries.  I was trying to finish up quickly before the long weekend.

I'd like to see atom:entry be able to have all four link rels.  Feed should be 
able to express (all but down).

The reason for multiple is that multiple ups are currently allowed.  That is a 
good solution if the resource exists in multiple independent hierarchies.

If there is no reason to prohibit, we probably should not.

I am not sure I follow your reasoning about atom:entry allowed to contain 
atom:entry if there is not a feed with the same set, edit or self link rels. 
Where is this stated in an rfc or is this reasoning you are proposing?

Best, Al
Sent from BlackBerry.

----- Original Message -----
From: "Nikunj R. Mehta" [EMAIL PROTECTED]
Sent: 05/26/2009 01:58 PM MST
To: Al Brown
Cc: atom-protocol Protocol <[EMAIL PROTECTED]>
Subject: Re: Hierarchy ID draft

Hi Al,

Apologies for responding to the feedback after a prolonged gap. An
intervening holiday and vacation delayed this. Nevertheless, this is
very useful feedback.

Section 2.1

Alternate links may be used in any and every Atom document. I am not
sure what you are alluding to.

For definitional purposes, the presence of an "up" link makes an entry
a child entry and the presence of a "down" link makes an entry a
parent entry. Any entry can choose to not include either or both of
these links. This I-D disallows the use of multiple link elements with
@rel="down", @rel="down-tree", @rel="up" and @rel="up-tree" directly
within a single entry. There is precedent to specifying cardinality in
link relations within Atom and I don't see a use case that will be
disallowed by this I-D.

I spotted the error in the illustration for child entry - it could
state atom:entry instead of atom:feed. All the same, a feed can also
use the "up" and "up-tree" relations just like a child entry.

Section 2.2

Clarifying the containment model is also necessary for definitional
purposes. Again, definitions are non-normative, unless explicitly
stated using RFC2117 mechanisms. Does this cause any difficulties in
reviewing or implementing the spec?

Section 3

Both mechanisms, the one you suggest and the one in the hierarchy I-D,
introduce the same kind of "burden" on processors - interpreting Atom
markup inside Atom markup beyond what is described by the non-
normative Atom RNG schema described in RFC 4287.

The inline representation is a convenience mechanism where feed and
entry documents can be housed within another Atom document. Servers
have the option of specifying out-of-line content instead of using the
inline representation. Therefore, it appears that the mechanism
described in the I-D is better suited to the inline representation

You are free to use the nested atom:entry inside atom:entry whenever
the nested entry does not have any "self" or "edit" URI. Also, you are
free to nest multiple atom:entry documents inside an atom:entry
whenever there is no atom:feed that forms the same set of entries as
the nested entries. However, this I-D does not address such a
requirement because no relation is implied between the nested entry
and contained entries. Specifying a relation is done using a link
element, and that requires an href value.

Doing what you suggest would require creation of two different
mechanisms for the same thing modulo the server's ability to generate
a URI. Would you mind describing why it would be not the right thing
for a server to generate an href value, if it cares for the relation
between entries?


On May 22, 2009, at 4:48 PM, Al Brown wrote:


Thanks for coming up with the split draft[1] based on the wg call.

Section 2.1:
1.On a feed, it would be worthwhile to have the alternate
representation (e.g., down or down-tree) as a link.
2. Down - this can be 0..1 rather than 1..1. Some entries may be
leafs. It might be better to not specify cardinality in the basic ID
3.On an entry, I'd like to be able to specify up and up-tree.

Section 2.2 - I would prefer the hierarchy navigation ID to be only
about navigation. This section describes containment behaviors to be
inclusive of a node being in more than one location in the graph.
Even though it is permissive, I am not sure this ID should say
anything about the containment model.

Section 3
1. I would prefer a much simpler model rather than containing in
link elements. It seems much more natural to represent down-tree as:
<atom:entry> </atom:entry>

or even

<atom:entry> </atom:entry>

One of the issues we have discussed on the wg, is what if the
hierarchy does not want to be represented as a link? E.g., that
portion of the tree does not have a URL at all? In this model, every
node has to have an URI associated with it and that URI has to be
calculated. How would I in the atom document format describe a tree
that is self contained?


Al Brown
Emerging Standards and Industry Frameworks
Industry Frameworks:

Office 714 327 3453
Mobile 714 263 6441
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.