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

From: "Nikunj R. Mehta" <[email-masked]>
Date: Fri, 5 Jun 2009 10:55:16 -0700

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-masked]>
> Date: June 5, 2009 10:06:45 AM PDT
> To: [email-masked]
> Cc: [email-masked]
> 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.
>
>

---

From: Al Brown <[email-masked]>
Date: Fri, 5 Jun 2009 14:06:06 -0700

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-masked]
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-masked]>                                                                       
                                                                                                                                
  To:         Atom-Syntax Syntax <[email-masked]>                                                                          
                                                                                                                                
  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:

      Abstract:

      The IETF Secretariat.

---

From: James M Snell <[email-masked]>
Date: Mon, 08 Jun 2009 11:56:28 -0700

Comments below...

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.
>
in-lining arbitrarily complex hierarchies is always going to be 
problematic and suboptimal... which is why I was so adamant about not 
baking hierarchy into Atom and Atompub in the first place when we were 
working on all this stuff initially.  Despite the added verbosity that 
this approach adds, however, I think it's likely the most acceptable 
approach.

> 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>
> ...
> 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.
>
Hmmm.... I know we've discussed this, but after thinking about it more 
and looking through the examples, I'm becoming increasingly less 
convinced that we need a distinction between "down" and "down-tree".  
One should simply assume that "down" could point to a child entry or 
child feed and that those children could potentially also be parents. 
Yes, that possibly increases the processing compexity but I think it 
simplifies the model overall.

> 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?
>
I think we can address this by eliminating the restriction that "down" 
and "up" must always point to Atom feed documents and by changing the 
cardinality rules for those links. That restriction, I think, is 
arbitrary and unnecessary

It would allow us to do something like....

<atom:entry>
...
<atom:link rel="down" type="application/atom+xml;type=entry" href="child1">
<ae:inline>
<atom:entry>...</atom:entry>
</ae:inline>
</atom:link>
<atom:link rel="down" type="application/atom+xml;type=entry" href="child2">
<ae:inline>
<atom:entry>...</atom:entry>
</ae:inline>
</atom:link>
...
<atom:link rel="down" type="application/atom+xml;type=entry" href="childN">
<ae:inline>
<atom:entry>...</atom:entry>
</ae:inline>
</atom:link>
...
</atom:entry>

Unlike any of the other methods discussed, this approach would allow 
clients that don't understand the hierarchy model to still understand 
that there is some kind of link relationship with each of the individual 
child resources and eliminates the need to include the extraneous 
atom:feed metadata.

Note that this is the same basic approach taken by my comment thread 
extension (in-reply-to).

- James

---

From: "Nikunj R. Mehta" <[email-masked]>
Date: Mon, 8 Jun 2009 12:15:34 -0700

> 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)
> href="/finance/feeds-tree/default/portfolios/1/positions" />

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.

> 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:
> 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
> 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.
>
> "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
>
> From:	
> "Nikunj R. Mehta" <[email-masked]>
> To:	
> 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

---

From: Al Brown <[email-masked]>
Date: Mon, 8 Jun 2009 12:49:36 -0700

I withdraw the proposal/plea for a simpler, less verbose mechanism for
expressing a hierarchy in atom in a single document.  Since the group finds
value in a generic mechanism and would be useful as well for CMIS in
non-hierarchy use cases, I doubt it makes sense to standardize two
approaches for the same similar functionality.

If it is not a huge cost, I would prefer the generic inlining mechanism to
be a separate I-D since it is only generically related to hierarchy.

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

I don't actually see a need to resolve multiple occurrences of that
relation.  Multiple relations of 'up' are multiple parents - feeds or
entries.  Multiple relations of 'down' are multiple children.  The client
can chose to follow none, one or all of those links.  In most scenarios,
there will probably only be one up and one down link relation though.
Changing MUST to SHOULD would be better, though omitting that statement
entirely would be better.

I see a problem with that restriction in RC4287 in exposing alternate
renditions/transcodings of that resource specifically when the variance
happens inside the media type and is not language-specific  such as bit
rate (low or high bandwidth video) or height and width (color vs b/w,
small, medium or large).  It is one of the reasons why I prefer not to
state items in a specification unless there is clear reason to do so.  This
is actually a problem for CMIS in leveraging alternate link relation in
exposing image representation of resources as there may be more than one
thumbnail of different sizes. Another use case is different image
representation of CAD drawings at different scale or orientation.

-Al

Al Brown

Office 714 327 3453
Mobile 714 263 6441

                                                                                                                                
  To:         Al Brown/Costa Mesa/IBM@IBMUS                                                                                     
                                                                                                                                
  Cc:         Atom-Syntax Syntax <[email-masked]>                                                                          
                                                                                                                                
  Date:       06/08/2009 12:17 PM                                                                                               
                                                                                                                                
  Subject:    Re: New Version Notification for draft-divilly-atom-hierarchy-01                                                  

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

      ...
      </atom:entry>
      </atom:feed>
      </ae:inline>

      ...
      </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).

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.

      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.

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

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

      >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]

      Al Brown

      Office 714 327 3453
      Mobile 714 263 6441

      "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

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

            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:

      Begin forwarded message:
                  From: IETF I-D Submission Tool <[email-masked]>
                  Date: June 5, 2009 10:06:45 AM PDT
                  To: [email-masked]
                  Cc: [email-masked]
                  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.

                  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.

---

From: Hadrien Gardeur <[email-masked]>
Date: Mon, 8 Jun 2009 21:54:46 +0200

James,

Hmmm.... I know we've discussed this, but after thinking about it more and
> looking through the examples, I'm becoming increasingly less convinced that
> we need a distinction between "down" and "down-tree".  One should simply
> assume that "down" could point to a child entry or child feed and that those
> children could potentially also be parents. Yes, that possibly increases the
> processing compexity but I think it simplifies the model overall.

I agree, and I've implemented hierarchy using strictly link@rel="down"
instead of "down-tree" for the same reason.

> I think we can address this by eliminating the restriction that "down" and
> "up" must always point to Atom feed documents and by changing the
> cardinality rules for those links. That restriction, I think, is arbitrary
> and unnecessary

I agree about the type: it could be useful to use a "down" link on something
else than a feed.
Not sure about cardinality though, moving from a tree model to a graph model
really make things more complex (more flexible and powerful too).

> clients that don't understand the hierarchy model to still understand that
> there is some kind of link relationship with each of the individual child
> resources and eliminates the need to include the extraneous atom:feed
> metadata.
>

The hierarchy I-D used to have ah:count to indicate the number of entries in
the child feed. Now that Nikunj removed ah:count from the draft, do you
believe that thr:count from your Atom threading extension could be used on
link@type="application/atom+xml;type=feed" for hierarchy ?

Hadrien

---

From: James M Snell <[email-masked]>
Date: Mon, 08 Jun 2009 13:09:16 -0700

+1

Al Brown wrote:
>
> [snip]
>
> If it is not a huge cost, I would prefer the generic inlining 
> mechanism to be a separate I-D since it is only generically related to 
> hierarchy.
>
> [snip]

---

From: James M Snell <[email-masked]>
Date: Mon, 08 Jun 2009 13:05:14 -0700

Hadrien Gardeur wrote:
> James,
>
>     Hmmm.... I know we've discussed this, but after thinking about it
>     more and looking through the examples, I'm becoming increasingly
>     less convinced that we need a distinction between "down" and
>     "down-tree".  One should simply assume that "down" could point to
>     a child entry or child feed and that those children could
>     potentially also be parents. Yes, that possibly increases the
>     I think we can address this by eliminating the restriction that
>     "down" and "up" must always point to Atom feed documents and by
>     changing the cardinality rules for those links. That restriction,
>     I think, is arbitrary and unnecessary
>
>
> I agree about the type: it could be useful to use a "down" link on 
> something else than a feed.
> Not sure about cardinality though, moving from a tree model to a graph 
> model really make things more complex (more flexible and powerful too).
Yes, there is the potential for making things a lot more complex but the 
definition of the "down" and "up" links shouldn't rule it out. Whether 
or not to use a tree or graph should be up to the application. However, 
we should be able to use the same link relations for either model.
>  
>
>     Unlike any of the other methods discussed, this approach would
>     allow clients that don't understand the hierarchy model to still
>     understand that there is some kind of link relationship with each
>     of the individual child resources and eliminates the need to
>     include the extraneous atom:feed metadata.
>
>     Note that this is the same basic approach taken by my comment
>     thread extension (in-reply-to).
>
>
> The hierarchy I-D used to have ah:count to indicate the number of 
> entries in the child feed. Now that Nikunj removed ah:count from the 
> draft, do you believe that thr:count from your Atom threading 
> extension could be used on link@type="application/atom+xml;type=feed" 
> for hierarchy ?
>
Potentially. I don't see why it couldn't be used for that.

- James

---

From: "Nikunj R. Mehta" <[email-masked]>
Date: Mon, 8 Jun 2009 13:13:37 -0700

On Jun 8, 2009, at 11:56 AM, James M Snell wrote:

<snip>

>> enclosing entry (id, uri, etc). Can't we do better for this  
>> specific scenario the I-D is addressing?
>>
> changing the cardinality rules for those links. That restriction, I  
> think, is arbitrary and unnecessary
>
> clients that don't understand the hierarchy model to still  
> understand that there is some kind of link relationship with each of  
> the individual child resources and eliminates the need to include  
> the extraneous atom:feed metadata.

I don't find this argument quite convincing. For starters, if a client  
doesn't understand rel="down" it will make no difference whether there  
are multiple of those or a single one. Secondly, a client that does  
the most generic thing possible can at least "render" a feed provided  
in @rel=down in a cogent way. A feed that has rel=down scattered all  
over the place will be more harmful than beneficial.

I can see how there is value in sporting a more flexible (and hence a  
more complex) model, I fail to see requirements for adding this  
complexity. Rather than treating the hierarchy I-D approach as  
arbitrary, I implore the group to identify reasons to expand the  
cardinality before making this arbitrary choice.

> Note that this is the same basic approach taken by my comment thread  

The whole processing model for multiple occurrences of @rel="replies"  
is underwhelming. From RFC 4685, Section 4,

Multiple replies links appearing within an atom:entry may reference  
alternative representations of the same set of responses or may  
reference entirely distinct resources containing distinct sets of  
responses.  Processors MUST NOT assume that multiple replies links are  
referencing different representations of the same resource and MUST  
process each replies link independently of any others.

I would be interested in learning about the usage experience with  
multiple links for replies, especially in consumers of documents using  
replies links with multiple occurrences.

---

From: "Nikunj R. Mehta" <[email-masked]>
Date: Mon, 8 Jun 2009 13:15:38 -0700

On Jun 8, 2009, at 12:54 PM, Hadrien Gardeur wrote:

<snip>

> I agree, and I've implemented hierarchy using strictly  
> link@rel="down" instead of "down-tree" for the same reason.
>

<snip>

I can see how we can add a default of type="application/atom 
+xml;type=feed" to @rel=down. The I-D already allows the link to be  
used with other types.

---

From: James M Snell <[email-masked]>
Date: Mon, 08 Jun 2009 13:30:58 -0700

Nikunj R. Mehta wrote:
>> that there is some kind of link relationship with each of the 
>> individual child resources and eliminates the need to include the 
>> extraneous atom:feed metadata.
>
A client that does not understand anything about "down" or "up" will not 
be able to do anything cogent with the linked resource other than say 
that some kind of relationship exists.  The ability to render the linked 
resource is meaningless if the application is incapable of determining 
the nature of the relationship.  In such cases, the distinction of 
having multiple rel=downs that point to alternate representations of the 
same resource or that point to separate distinct resources is 
meaningless and neither approach is more or less harmful or beneficial 
than the other.
> cardinality before making this arbitrary choice.
This is backwards. Cardinality constraints are a restriction. To ensure 
maximum flexibility, one needs to justify adding the restriction, not 
justify removing it. All that I'm saying is that the existing 
cardinality rules impose a restriction on the model that does not appear 
to be strictly necessary and could potentially be harmful long term. For 
instance, given the current definition, one would need to invent yet 
another set of hierarchy rel relations in order to implement a graph 
model, which, to me at least, seems counterproductive. Define "down" and 
"up" more generically and move the cardinality constraints to the 
application where they belong.  Note that relaxing the cardinality does 
not make it any more difficult to achieve the result you are looking 
for.  An application could still use multiple rel=down links to point to 
alternate language representations of the same logical child feed, for 
instance, Atom processors would simply treat those alternate language 
representations as separate child feeds leaving it up to the application 
to make the appropriate connections.
> replies links with multiple occurrences.
I would be interested in learning about the implementation experiences 
for this as well.  I purposefully left that model to be as flexible as 
possible, with as few constraints as possibly, specifically in order to 
avoid placing arbitrary and premature restrictions on implementations. 
If implementation experience shows that specific restrictions would be 
helpful, then I would be more than happy to work on a BCP describing 
those restrictions.

- James

---

From: Al Brown <[email-masked]>
Date: Mon, 8 Jun 2009 15:11:10 -0700

>simplifies the model overall.

We've discussed this today on the phone.  For me this is a difference of
protocol/hypermedia vs. syntax.  For syntax, "down" and "up" are
sufficient.  A flat model can modeled with feed and a tree can be modeled
using generic inlining in a feed or entry.

A client requests an atom document - entry or feed.  How does the server
advertise to the client, via what is in the atom document, here are two
links to representations (flat vs. tree) of a resource, e.g. the folder's
children:  one link returns a flat list (no inlining) and one link returns
a tree (inlined).  Both are the same document just with or without inlining
of linked resources of a particular link relation.  Since the resources are
crossing the wire, the first resource (e.g., folder) needs to convey how
access a hierarchical resource (e.g., items in a folder) in either a flat
mode (feed) or tree (feed with inlined resources).

The options I see are:
a. append -tree to link relations that may inline (e.g., down-tree,
up-tree).  Not so nice, but works.
b. add a new attribute to link that specifies if they are inlined
      (down) <link rel="down" href="http://www.example.com/foo/down" />
      (down-tree) <link rel="down" ah:inlined="true"
href="http://www.example.com/foo/down/inlined" />
      This adds complexity if there are cardinality constraints on link
relations such as alternate and clients not aware of I-D may think they are
the same.
c. leverage link templates rather than link relations
d. use out of band communication - append a uri argument such as
includeLinkRel=down to the URI of the resource; could also be HTTP header.
Not very RESTful but works.

If the model is not sufficient to convey to the client here's a flat mode
vs. here's a tree mode, CMIS will have to find another alternative as it is
currently required by the CMIS domain model.

I see the options for CMIS as:
1. Leverage the model specified by the I-D if exists (best)
2. Move down-tree to CMIS namespace.  This does not solve the
protocol/hypermedia problem for anybody else.
3. Specify in the CMIS specification an URI argument to enable inlining of
'down'.

-Al

Al Brown

Office 714 327 3453
Mobile 714 263 6441

  From:       James M Snell <[email-masked]>                                                                                 

  Cc:         "Nikunj R. Mehta" <[email-masked]>, Atom-Syntax Syntax <[email-masked]>,                            
              [email-masked]                                                                                    
                                                                                                                                
  Date:       06/08/2009 11:55 AM                                                                                               
                                                                                                                                
  Subject:    Re: Fwd: New Version Notification for draft-divilly-atom-hierarchy-01                                             

Comments below...

<atom:entry>
...

- James

---

From: "Nikunj R. Mehta" <[email-masked]>
Date: Mon, 8 Jun 2009 15:30:04 -0700

As I see it, whether there is a @rel=down-tree or not, you would have  
to communicate certain information out-of-band, e.g., depth of the  
tree or the level of completeness in every in-lined entry.

Atom does not provide any means of advertising URIs for retrieving  
representation variants. This could be a source of your  
dissatisfaction but it applies equally well regardless of hierarchy or  
in-lining.

On Jun 8, 2009, at 3:11 PM, Al Brown wrote:

> more
> We've discussed this today on the phone.  For me this is a  
> difference of protocol/hypermedia vs. syntax.  For syntax, "down"  
> and "up" are sufficient.  A flat model can modeled with feed and a  
> tree can be modeled using generic inlining in a feed or entry.
>
> A client requests an atom document - entry or feed.  How does the  
> server advertise to the client, via what is in the atom document,  
> here are two links to representations (flat vs. tree) of a resource,  
> e.g. the folder's children:  one link returns a flat list (no  
> inlining) and one link returns a tree (inlined).
>
It is no different from seeing an HTML vs. a PDF representation of the  
same blog entry. One gives you a lot of context such as comments,  
related posts, advertisements and the like, and the other may be  
limited. This problem, AFAICT, exists regardless of CMIS or hierarchy.
> Both are the same document just with or without inlining of linked  
> resources of a particular link relation.
>
For all practical purposes, they are different documents, i.e.,  
different representations of a single resource.

> Since the resources are crossing the wire, the first resource (e.g.,  
> folder) needs to convey how access a hierarchical resource (e.g.,  
> items in a folder) in either a flat mode (feed) or tree (feed with  
> inlined resources).
>
> The options I see are:
It may not be specific enough anyway to say this is a tree link  
because it says nothing about depth
> (down-tree) <link rel="down" ah:inlined="true" href="http://www.example.com/foo/down/inlined 
> " />
> relations such as alternate and clients not aware of I-D may think  
> they are the same.
>
IMHO, ah:inlined does nothing because the presence of ae:inline makes  
it plenty clear. If you were trying to say that there is a certain  
level of depth in the tree, may be an attribute would help, but even  
then you don't know what things the server may have elided from every  
entry. So, bottom line is, there is not much value to an attribute to  
describe the thing that is in-lined. You are best off using what you  
have received as an approximation and then get the exact  
representation if you care so much in a separate network call. Of  
course, out-of-band communication or specialized mark-up may provide  
enough information for you to avoid such round-trips.
> c. leverage link templates rather than link relations
I am not aware of "link templates". If you are referring to draft- 
gregorio-uri-templates, then too there is no notion of templates baked  
in to the link element yet.
> includeLinkRel=down to the URI of the resource; could also be HTTP  
> header. Not very RESTful but works.
>
> If the model is not sufficient to convey to the client here's a flat  
> mode vs. here's a tree mode, CMIS will have to find another  
> alternative as it is currently required by the CMIS domain model.
>
> 3. Specify in the CMIS specification an URI argument to enable  
> inlining of 'down'.
>
> -Al
>
> Al Brown
> James M Snell ---06/08/2009 11:55:37 AM---Comments  
> below...
>
> From:	
> James M Snell <[email-masked]>
> To:	
> Cc:	
> "Nikunj R. Mehta" <[email-masked]>, Atom-Syntax Syntax <[email-masked] 
> >, [email-masked]
> Date:	
> 06/08/2009 11:55 AM
> Subject:	
> Re: Fwd: New Version Notification for draft-divilly-atom-hierarchy-01
>
>
>
> Comments below...
>
> Al Brown wrote:
> >
> included
> individual

---

From: James M Snell <[email-masked]>
Date: Mon, 08 Jun 2009 15:39:39 -0700

Nikunj R. Mehta wrote:
> to communicate certain information 
> out-of-band, e.g., depth of the tree or the level of completeness in every in-lined entry.  
>
>
Right, which is why I'm not sure if the distinction between down and 
down-tree is meaningful enough. You're still going to have to look at 
the out-of-band info to figure out what you need to do with it.

+1
> I am not aware of "link templates". If you are referring to 
> draft-gregorio-uri-templates, then too there is no notion of templates 
> baked in to the link element yet.
This came from a discussion Al and I were having offline.  Basically, 
I've worked up some ideas on how to use Joe G.'s URI templates within an 
Atom entry as a form of link-template.  I need to get that fully documented.

- James

---

From: Al Brown <[email-masked]>
Date: Mon, 8 Jun 2009 15:44:55 -0700

b. add a new attribute to link that specifies if they are inlined
      (down) <link rel="down" href="http://www.example.com/foo/down" />
      (down-tree) <link rel="down" ah:inlined="true" href="
      http://www.example.com/foo/down/inlined" />
      This adds complexity if there are cardinality constraints on link
      relations such as alternate and clients not aware of I-D may think
      they are the same.

>IMHO, ah:inlined does nothing because the presence of ae:inline makes it
plenty clear. If you were trying to say that there is a certain level of
depth in the tree, may >be an attribute would help, but even then you don't
know what things the server may have elided from every entry. So, bottom
line is, there is not much value to an >attribute to describe the thing
that is in-lined. You are best off using what you have received as an
approximation and then get the exact representation if you care so >much in
a separate network call. Of course, out-of-band communication or
specialized mark-up may provide enough information for you to avoid such
round-trips.

Maybe I did not explain clearly enough - this is a protocol/hypermedia
issue.  How does the client say (follow the right link relation) I want an
inlined representation of this resource specified by a link relation?
E.g.,

Client (C) navigates to this atom entry (A) somehow.  A wants to advertise
to the client that A has references to two to representations for resource
B.  One version of B is flat (ala a feed).  One version of B is the same
flat feed with its link relations inlined (ala tree).

How can resource A provide the client C with information there are two
choices available for B (flat vs tree)?

-Al

Al Brown

Office 714 327 3453
Mobile 714 263 6441

                                                                                                                                
                                                                                                                                
  Cc:         James M Snell <[email-masked]>, atom-syntax Syntax <[email-masked]>                                       
                                                                                                                                
  Date:       06/08/2009 03:33 PM                                                                                               

As I see it, whether there is a @rel=down-tree or not, you would have to
communicate certain information out-of-band, e.g., depth of the tree or the
level of completeness in every in-lined entry.

Atom does not provide any means of advertising URIs for retrieving
representation variants. This could be a source of your dissatisfaction but
it applies equally well regardless of hierarchy or in-lining.

      more

      >simplifies the model overall.

      We've discussed this today on the phone.  For me this is a difference
      of protocol/hypermedia vs. syntax.  For syntax, "down" and "up" are
      sufficient.  A flat model can modeled with feed and a tree can be
      modeled using generic inlining in a feed or entry.

It is no different from seeing an HTML vs. a PDF representation of the same
blog entry. One gives you a lot of context such as comments, related posts,
advertisements and the like, and the other may be limited. This problem,
AFAICT, exists regardless of CMIS or hierarchy.

For all practical purposes, they are different documents, i.e., different
representations of a single resource.

      The options I see are:

It may not be specific enough anyway to say this is a tree link because it
says nothing about depth

      b. add a new attribute to link that specifies if they are inlined
      (down) <link rel="down" href="http://www.example.com/foo/down" />
      (down-tree) <link rel="down" ah:inlined="true" href="
      http://www.example.com/foo/down/inlined" />
      This adds complexity if there are cardinality constraints on link
      relations such as alternate and clients not aware of I-D may think
      they are the same.

IMHO, ah:inlined does nothing because the presence of ae:inline makes it
plenty clear. If you were trying to say that there is a certain level of
depth in the tree, may be an attribute would help, but even then you don't
know what things the server may have elided from every entry. So, bottom
line is, there is not much value to an attribute to describe the thing that
is in-lined. You are best off using what you have received as an
approximation and then get the exact representation if you care so much in
a separate network call. Of course, out-of-band communication or
specialized mark-up may provide enough information for you to avoid such
round-trips.

      -Al

      Al Brown

      Office 714 327 3453
      Mobile 714 263 6441

 <ecblan                                                      
 k.gif>  James M Snell <[email-masked]>                                 
 From:                                                                     
                                                                           
 <ecblan                                                      
 k.gif>  Al Brown/Costa Mesa/IBM@IBMUS                                     
 To:                                                                       
                                                                           
 <ecblan                                                      
 k.gif>  "Nikunj R. Mehta" <[email-masked]>, Atom-Syntax Syntax < 
 Cc:     [email-masked]>, [email-masked]              
                                                                           
 <ecblan                                                      
 k.gif>  06/08/2009 11:55 AM                                               
 Date:                                                                     
                                                                           
 <ecblan                                                      
 k.gif>  Re: Fwd: New Version Notification for                             
 Subject draft-divilly-atom-hierarchy-01                                   
 :                                                                         

      Comments below...

      baking hierarchy into Atom and Atompub in the first place when we
      were
      working on all this stuff initially.  Despite the added verbosity
      that
      this approach adds, however, I think it's likely the most acceptable
      approach.

      > First example: there are two down relations: down and down-tree. It
      is

      included

      "down"

      <atom:entry>
      ...
      <atom:link rel="down" type="application/atom+xml;type=entry"
      href="child1">
      <ae:inline>
      <atom:entry>...</atom:entry>
      </ae:inline>
      </atom:link>
      <atom:link rel="down" type="application/atom+xml;type=entry"
      href="child2">
      <ae:inline>
      <atom:entry>...</atom:entry>
      </ae:inline>
      </atom:link>
      ...
      <atom:link rel="down" type="application/atom+xml;type=entry"
      href="childN">
      <ae:inline>
      <atom:entry>...</atom:entry>
      </ae:inline>
      </atom:link>
      ...
      </atom:entry>

      - James

---

From: James M Snell <[email-masked]>
Date: Mon, 08 Jun 2009 15:51:24 -0700

Al Brown wrote:
>             (down) <link rel="down"
>             href="_http://www.example.com/foo/down_" />
>             href="_http://www.example.com/foo/down/inlined_" />
>             This adds complexity if there are cardinality constraints
>             on link relations such as alternate and clients not aware
>             of I-D may think they are the same. 
>
> level of depth in the tree, may >be an attribute would help, but even 
> entry. So, bottom line is, there is not much value to an >attribute to 
> representation if you care so >much in a separate network call. Of 
> issue. How does the client say (follow the right link relation) I want 
> an inlined representation of this resource specified by a link 
> relation? E.g.,
>
> Client (C) navigates to this atom entry (A) somehow. A wants to 
> advertise to the client that A has references to two to 
> representations for resource B. One version of B is flat (ala a feed). 
> One version of B is the same flat feed with its link relations inlined 
> (ala tree).
>
Such distinctions are usually made by looking at the content-type of the 
linked resource. Again, forgive me if this has already been discussed 
elsewhere in this thread, but I would think that some kind of variation 
on the link type attribute would be appropriate. Perhaps something like 
the profile media type parameter that has been kicked around before?

e.g. (just a strawman)

  <link rel="down" type="application/atom+xml;type=feed;profile=tree" 
href="..." />
  <link rel="down" type="application/atom+xml;type=feed;profile=flat" 
href="..." />

- James
> 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 
> 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.
>
> Inactive hide details for "Nikunj R. Mehta" ---06/08/2009 03:33:06 
> PM---As I see it, whether there is a @rel=down-tree or not, "Nikunj R. 
> Mehta" ---06/08/2009 03:33:06 PM---As I see it, whether there is a 
> @rel=down-tree or not, you would have to communicate certain 
> information out-of-band, e.g., dep
>
>
> From: 	
> Al Brown/Costa Mesa/IBM@IBMUS
>
> Cc: 	
> James M Snell <[email-masked]>, atom-syntax Syntax 
> <[email-masked]>
>
> Date: 	
> 06/08/2009 03:33 PM
>
> Subject: 	
> Re: New Version Notification for draft-divilly-atom-hierarchy-01
>
> ------------------------------------------------------------------------
>
>
>
>             difference of protocol/hypermedia vs. syntax.  For syntax,
>             "down" and "up" are sufficient.  A flat model can modeled
>             with feed and a tree can be modeled using generic inlining
>             in a feed or entry.
>
>             A client requests an atom document - entry or feed.  How
>             does the server advertise to the client, via what is in
>             the atom document, here are two links to representations
>             (flat vs. tree) of a resource, e.g. the folder's children:
>              one link returns a flat list (no inlining) and one link
>             returns a tree (inlined).   
>
>             Both are the same document just with or without inlining
>             of linked resources of a particular link relation.   
>
>             Since the resources are crossing the wire, the first
>             resource (e.g., folder) needs to convey how access a
>             hierarchical resource (e.g., items in a folder) in either
>             a flat mode (feed) or tree (feed with inlined resources).
>
>             The options I see are:
>             a. append -tree to link relations that may inline (e.g.,
>             down-tree, up-tree). Not so nice, but works. 
>
>             (down) <link rel="down"
>             href="_http://www.example.com/foo/down_" />
>             href="_http://www.example.com/foo/down/inlined_" />
>             This adds complexity if there are cardinality constraints
>             on link relations such as alternate and clients not aware
>             of I-D may think they are the same. 
>
>             d. use out of band communication - append a uri argument
>             such as includeLinkRel=down to the URI of the resource;
>             could also be HTTP header. Not very RESTful but works.
>
>             If the model is not sufficient to convey to the client
>             here's a flat mode vs. here's a tree mode, CMIS will have
>             to find another alternative as it is currently required by
>             the CMIS domain model.
>
>             2. Move down-tree to CMIS namespace. This does not solve
>             the protocol/hypermedia problem for anybody else.
>             3. Specify in the CMIS specification an URI argument to
>             enable inlining of 'down'.
>
>             -Al
>
>             Al Brown
>             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-masked]
>             <mailto:[email-masked]>
>             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.
>
>             James M Snell ---06/08/2009 11:55:37
>             AM---Comments below...
>             From: 	
>             James M Snell <[email-masked]
>             <mailto:[email-masked]>>
>             To: 	
>             Al Brown/Costa Mesa/IBM@IBMUS
>             Cc: 	
>             "Nikunj R. Mehta" <[email-masked]
>             <mailto:[email-masked]>>, Atom-Syntax Syntax
>             <[email-masked] <mailto:[email-masked]>>,
>             [email-masked]
>             <mailto:[email-masked]>
>             Date: 	
>             06/08/2009 11:55 AM
>             Subject: 	
>             ------------------------------------------------------------------------
>
>
>
>             Comments below...
>
>             Al Brown wrote:
>             >
>             type="application/atom+xml;type=feed"
>             type="application/atom+xml;type=entry" href="child1">
>             <ae:inline>
>             type="application/atom+xml;type=entry" href="child2">
>             <ae:inline>
>             type="application/atom+xml;type=entry" href="childN">
>             <ae:inline>
>             understand

---

From: "Nikunj R. Mehta" <[email-masked]>
Date: Mon, 8 Jun 2009 15:51:40 -0700

> <link rel="down" type="application/atom+xml;type=feed;profile=flat"  

Just a nit, media type parameters are ',' separated, correct?.

---

From: James M Snell <[email-masked]>
Date: Mon, 08 Jun 2009 15:55:31 -0700

Heh, I think so ;-)

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 09 Jun 2009 01:06:30 +0200

>Just a nit, media type parameters are ',' separated, correct?.

No, by ";", see e.g. RFC 2045.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Al Brown <[email-masked]>
Date: Mon, 8 Jun 2009 16:10:13 -0700

>> <link rel="down" type="application/atom+xml;type=feed;profile=flat"

This works for me.  I would like to see the extension to the media type in
the I-D instead of "down-tree" and "up-tree".

-Al

Al Brown

Office 714 327 3453
Mobile 714 263 6441

                                                                                                                                
  To:         "Nikunj R. Mehta" <[email-masked]>                                                                       
                                                                                                                                
  Cc:         Al Brown/Costa Mesa/IBM@IBMUS, atom-syntax Syntax <[email-masked]>                                           
                                                                                                                                
  Date:       06/08/2009 03:54 PM                                                                                               

Heh, I think so ;-)

---

From: "Nikunj R. Mehta" <[email-masked]>
Date: Mon, 8 Jun 2009 16:14:59 -0700

I am not sure if a media type parameter for Atom would be within the  
scope of an inline extension for Atom.

Nikunj

On Jun 8, 2009, at 4:10 PM, Al Brown wrote:

> This works for me. I would like to see the extension to the media  
> type in the I-D instead of "down-tree" and "up-tree".
>
> -Al
>
> Al Brown
> James M Snell ---06/08/2009 03:54:38 PM---Heh, I think  
> so ;-)
>
> From:	
> Al Brown/Costa Mesa/IBM@IBMUS, atom-syntax Syntax <atom- 
> [email-masked]>
> Date:	
> 06/08/2009 03:54 PM
> Subject:

---

From: [email-masked]
Date: Mon, 8 Jun 2009 23:22:34 +0000

Sure it would. Nonetheless, the profile media type extension should be defined separately in its own I-D. I can write that up. Been meaning to do so for a while. 

Sent from my Verizon Wireless BlackBerry

-----Original Message-----

Date: Mon, 8 Jun 2009 16:14:59 
To: Al Brown<[email-masked]>
Cc: James M Snell<[email-masked]>; atom-syntax Syntax<[email-masked]>
Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-01

Nikunj

---

From: "Nikunj R. Mehta" <[email-masked]>
Date: Mon, 8 Jun 2009 15:49:24 -0700

On Jun 8, 2009, at 3:44 PM, Al Brown wrote:

> >IMHO, ah:inlined does nothing because the presence of ae:inline  
> makes it plenty clear. If you were trying to say that there is a  
> certain level of depth in the tree, may >be an attribute would help,  
> but even then you don't know what things the server may have elided  
> from every entry. So, bottom line is, there is not much value to an  
> >attribute to describe the thing that is in-lined. You are best off  
> using what you have received as an approximation and then get the  
> exact representation if you care so >much in a separate network  
> call. Of course, out-of-band communication or specialized mark-up  
> may provide enough information for you to avoid such round-trips.
> Maybe I did not explain clearly enough - this is a protocol/ 
> hypermedia issue. How does the client say (follow the right link  
> relation) I want an inlined representation of this resource  
> specified by a link relation? E.g.,
>
The question is clearly phrased this time and I understand the  
intention. However, as I said in the previous message, modulo hreflang  
and type,

> representations for resource B.  One version of B is flat (ala a  
> feed). One version of B is the same flat feed with its link  
> relations inlined (ala tree).
>
> How can resource A provide the client C with information there are  
> two choices available for B (flat vs tree)?
>
Perhaps James Snell's template idea may be worth considering. I don't  
know yet.
> "Nikunj R. Mehta" ---06/08/2009 03:33:06 PM---As I see  
> it, whether there is a @rel=down-tree or not, you would have to  
> communicate certain information out-of-band, e.g., dep
>
> From:	
> James M Snell <[email-masked]>, atom-syntax Syntax <[email-masked] 
> >
> Date:	
> 06/08/2009 03:33 PM
> Subject:	
> As I see it, whether there is a @rel=down-tree or not, you would  
> have to communicate certain information out-of-band, e.g., depth of  
> the tree or the level of completeness in every in-lined entry.
>
> dissatisfaction but it applies equally well regardless of hierarchy  
> or in-lining.
>
> It is no different from seeing an HTML vs. a PDF representation of  
> the same blog entry. One gives you a lot of context such as  
> comments, related posts, advertisements and the like, and the other  
> may be limited. This problem, AFAICT, exists regardless of CMIS or  
> hierarchy.
> IMHO, ah:inlined does nothing because the presence of ae:inline  
> makes it plenty clear. If you were trying to say that there is a  
> certain level of depth in the tree, may be an attribute would help,  
> but even then you don't know what things the server may have elided  
> from every entry. So, bottom line is, there is not much value to an  
> attribute to describe the thing that is in-lined. You are best off  
> using what you have received as an approximation and then get the  
> exact representation if you care so much in a separate network call.  
> Of course, out-of-band communication or specialized mark-up may  
> provide enough information for you to avoid such round-trips.
> gregorio-uri-templates, then too there is no notion of templates

---

From: Peter Keane <[email-masked]>
Date: Tue, 9 Jun 2009 00:02:15 -0500

[snip]
>>
>> I can see how there is value in sporting a more flexible (and hence a more
>> complex) model, I fail to see requirements for adding this complexity.
>> Rather than treating the hierarchy I-D approach as arbitrary, I implore the
>> group to identify reasons to expand the cardinality before making this
>> arbitrary choice.
>>
> justify removing it. All that I'm saying is that the existing cardinality
> rules impose a restriction on the model that does not appear to be strictly
> necessary and could potentially be harmful long term. For instance, given
> the current definition, one would need to invent yet another set of
> hierarchy rel relations in order to implement a graph model, which, to me at
> least, seems counterproductive. Define "down" and "up" more generically and
> move the cardinality constraints to the application where they belong.  Note
> that relaxing the cardinality does not make it any more difficult to achieve
> the result you are looking for.  An application could still use multiple
> rel=down links to point to alternate language representations of the same
> logical child feed, for instance, Atom processors would simply treat those
> alternate language representations as separate child feeds leaving it up to
> the application to make the appropriate connections.

I am definitely in agreement w/ James here.  I'd like/need to be able
to have multiple 'up' and 'down' links of the same type and let the
application sort 'em out.  0:1 is a constraint I'd need to figure a
way around.

--peter