On Tue, Jun 2, 2009 at 12:58 PM, Al Brown <[email protected]> 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> >
Hi All- This option makes little sense to me in that it creates and represents a completely new type of "set" of atom entries that is in fact NOT a feed (more akin to a "bag" I suppose)? What relationship, if any do these children have to one another? I assume this is to represent a directory-tree like structure? If, so, I believe there are much better ways that do not break the the essential nature of Atom as documents and lists of documents. To quote Roy F. from a recent thread: "...Atom categories are analogous to folders in CMIS. It would make more sense to replace most of the CMIS extensions by using the Atom category mechanism to hold its filing relations. ....Roy" [http://www.imc.org/atom-protocol/mail-archive/msg11379.html] I other words, atom entries live in feeds that may bear no relationship to physical place on the filesystem. Those places are described in atom:category in entries, e.g.: <entry> <category term="/home"/> </entry> <entry> <category term="/home/peter"/> </entry> <entry> <category term="/home/peter/docs/> </entry> By the way, I have no problem w/ #1 above for inlining a feed. --peter > 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. > > "Nikunj R. Mehta" ---05/28/2009 12:32:53 PM---There is precedence to the > proposal I have submitted. GData uses > > > From: > "Nikunj R. Mehta" <[email protected]> > To: > Julian Reschke <[email protected]> > Cc: > Atom-Syntax Syntax <[email protected]> > Date: > 05/28/2009 12:32 PM > Subject: > 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 > > > >
