Just to be clear, I have no interest in option #2. In case CMIS ends
up using that mechanism it would be their choice and in their namespace.
I have provided several reasons why #2 is not a great idea [1] and
also realize that standardizing option #1 means adding new semantics
to Atom, i.e., revising Atom compatibly. It is very likely that such a
thing would be long drawn out but I am in favor of taking that
approach for the long run. I will continue to edit atompub-hierarchy I-
D [2] along with Colm Divilly and include the in-lining mechanisms
there.
Nikunj
http://o-micron.blogspot.com
[1] CMIS XV: Perils of embedding entry inside entry
[2] http://www.ietf.org/internet-drafts/draft-divilly-atompub-hierarchy-00.txt
On Jun 2, 2009, at 10:58 AM, Al Brown wrote:
This is to recap a discussion that happened on the cmis atom wg call
this morning and see if the group beyond Nikunj, Julian and I have
any preference for the options below. If this group does not have a
preference for any of the options, the representation of a tree
structure will be removed from the hierarchy I-D. This is deemed the
best course of action currently.
Due to the reasons already discussed by Julian and myself on this
list, CMIS will leverage option #2 if it is included in the I-D but
probably not option #1. #1 does not ideally address CMIS' use case
of how to represent a tree of atom entries in a single document but
rather provide a generic pre-fetching/inlining mechanism.
The options so far discussed are:
1. Including the resource itself inside <link>
>>> <atom:entry>
>>> <atom:link rel="down"
>>> href="/finance/feeds/default/portfolios/1/positions">
>>> <atom:feed>
>>> <atom:link rel="self"
>>> href="/finance/feeds/default/portfolios/1/positions"/>
>>> ...
>>> </atom:feed>
>>> </atom:link>
>>> ...
>>> </atom:entry>
2. Using an extension element in atom:entry to contain 0..n
atom:entry 's (could also include feed's though CMIS most likely
would not leverage that)
<atom:entry>
<ah:children>
<atom:entry>...</atom:entry>
</ah:children>
</atom:entry>
If there is not a consensus, then the representation of a tree
structure will be removed from the I-D by Nikunj in the next draft.
Thanks,
-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.
<graycol.gif>"Nikunj R. Mehta" ---05/28/2009 12:32:53 PM---There is
precedence to the proposal I have submitted. GData uses
<ecblank.gif>
From: <ecblank.gif>
"Nikunj R. Mehta" <[email protected]>
<ecblank.gif>
To: <ecblank.gif>
Julian Reschke <[email protected]>
<ecblank.gif>
Cc: <ecblank.gif>
Atom-Syntax Syntax <[email protected]>
<ecblank.gif>
Date: <ecblank.gif>
05/28/2009 12:32 PM
<ecblank.gif>
Subject: <ecblank.gif>
Re: New Version Notification for draft-divilly-atom-hierarchy-00
There is precedence to the proposal I have submitted. GData uses
feedLink [1] and entryLink [2] mechanisms in Google's own namespace to
include in-line representations of entries and feeds. Notice how these
elements have both @rel and @href, critical to the functioning of
Atom's own link mechanisms.
The atom-hierarchy-ID is merely trying to standardize such behavior
and not invent new behavior. Moreover, the proposed syntax is not
merely syntactically legal, it is also semantically valuable. There
are three benefits to this approach:
1. The context of the inlined feed or entry is immediately clear from
the @rel value
2. The server can choose to inline content as per requirements and
configuration
3. The format supports inlining of any number of entries - a single or
multiple. It also expresses the absence of any entries, when this is
required.
Which of these advantages can you claim for directly embedding an
entry inside another?
Nikunj
http://o-micron.blogspot.com
On May 27, 2009, at 5:12 AM, Julian Reschke wrote:
>
> Nikunj R. Mehta wrote:
>> On May 25, 2009, at 8:42 AM, Julian Reschke wrote:
>>> with respect to
<http://tools.ietf.org/html/draft-divilly-atom-hierarchy-00#section-3
>>> >, "Inline Representation of Hierarchical Resources"...
>>>
>>> It seems to be that using atom:link as a container elements
>>> stretches its semantics of "reference from an entry or feed to a
>>> Web resource" too much.
>> I don't agree with that. A previous discussion on this mailing list
>> more than a year ago [1] has already concluded that it is perfectly
>> legal to do so. Additionally, the hierarchy-ID approach appears
>> similar to the
>
> I do not agree with that conclusion, but nevertheless, just because
> something is syntactically legal doesn't make it a good choice.
>
> atom:link is defined to as:
>
> "The "atom:link" element defines a reference from an entry or feed
> to a Web resource."
>
> Inlining the content of referenced web resource is IMHO contrary to
> that definition.
>
>> approach taken by the RFC4287 with atom:content usage models, where
>> several options about inline and out-of-line content delivery are
>> available.
>
> But atom:content has been explicitly designed that way:
>
> "The "atom:content" element either contains or links to the content
> of the entry." --
<http://greenbytes.de/tech/webdav/rfc4287.html#rfc.section.4.1.3
> >
>
> while atom:link has not.
I respectfully disagree although you are entitled to your opinion.
Previous discussion on this mailing list [3], which included several
people who were part of the early crowd of atom-syntax, has made it
clear that one should not go by any prejudice about the lack of
specification of a certain previously undefined mark up usage.
>
>
> So I'll stick with my comment that atom:entry is better suited for
> that purpose, being defined as:
>
> "The "atom:entry" element represents an individual entry, acting
> as a container for metadata and data associated with the entry."
-- <http://greenbytes.de/tech/webdav/rfc4287.html#rfc.section.4.1.2
> >
>
>
>>> As Al pointed out on the CMIS mailing list
(<http://lists.oasis-open.org/archives/cmis/200905/msg00186.html
>>> >), it may be better to use a container element inside atom:entry.
>>>
>>> So, the example in
<http://tools.ietf.org/html/draft-divilly-atom-hierarchy-00#section-3.2.3
>>> >:
>>>
>>> <atom:entry>
>>> <atom:link rel="down"
>>> href="/finance/feeds/default/portfolios/1/positions">
>>> <atom:feed>
>>> <atom:link rel="self"
>>> href="/finance/feeds/default/portfolios/1/positions"/>
>>> ...
>>> </atom:feed>
>>> </atom:link>
>>> ...
>>> </atom:entry>
>>>
>>>
> > ...
>
> BTW: the format above is currently forbidden by the RNC (because of
> the use of the atom namespace for the contained element); I know
> that part of the spec is informative, but still...
>
Again, you are misleading the reader to assume that RNC schema is
normative. There is a very good reason for it to not be normative and
the spec editors were clear about them.
Nikunj
[1] http://code.google.com/apis/gdata/elements.html#gdFeedLink
[2] http://code.google.com/apis/gdata/elements.html#gdEntryLink
[3] http://www.imc.org/atom-syntax/mail-archive/msg20456.html
