atom-protocol

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
requirement.

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?

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



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

> Nikunj,
>
> 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> </atom:entry>
> ...
> </atom:entry>
>
> or even
>
> <atom:entry>
> <ah:children>
> <atom:entry> </atom:entry>
> ...
> </ah:children>
> </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?
>
> Thanks,
> -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.