-Al
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.
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:
"Nikunj R. Mehta" <[email protected]>
To:
Al Brown/Costa Mesa/i...@ibmus
Cc:
James M Snell <[email protected]>, atom-syntax Syntax
<[email protected]>
Date:
06/08/2009 03:33 PM
Subject:
Re: New Version Notification for draft-divilly-atom-hierarchy-01
------------------------------------------------------------------------
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:
James wrote:
>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.
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:
a. append -tree to link relations that may inline (e.g.,
down-tree, up-tree). Not so nice, but works.
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.
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.
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
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]_
<mailto:[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>James M Snell ---06/08/2009 11:55:37
AM---Comments below...
<ecblank.gif>
From: <ecblank.gif>
James M Snell <[email protected]_
<mailto:[email protected]>>
<ecblank.gif>
To: <ecblank.gif>
Al Brown/Costa Mesa/i...@ibmus
<ecblank.gif>
Cc: <ecblank.gif>
"Nikunj R. Mehta" <[email protected]_
<mailto:[email protected]>>, Atom-Syntax Syntax
<[email protected]_ <mailto:[email protected]>>,
[email protected]_
<mailto:[email protected]>
<ecblank.gif>
Date: <ecblank.gif>
06/08/2009 11:55 AM
<ecblank.gif>
Subject: <ecblank.gif>
Re: Fwd: New Version Notification for
draft-divilly-atom-hierarchy-01
------------------------------------------------------------------------
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.
> 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.
>
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.
> 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?
>
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
