abdera-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davis_Corne...@emc.com
Subject RE: Modeling Collections of Collections
Date Wed, 26 Sep 2007 06:13:09 GMT

I like it too actually.  It's absolutely legal from an Atom format
perspective because the <app:collection> children of the <atom:entry>
element are simply extensions - the APP aptly points out that "the
app:collection element is considered foreign markup as defined in
Section 6 of [RFC4287]."  Basically that means that anything written to
the Atom Syndication Format standard knows nothing about
app:collections.

But I believe we have to reach that same conclusion with respect to APP.
The way I read it, APP "allows" (or perhaps "defines") <app:collection>
elements in service documents or in <atom:feed> or <atom:source>
elements, the behavior with the latter two being that it provides URIs
that allow for entries to be added to that feed.  So technically, this
proposal, where an <app:collection> appears within an <atom:entry> is an
extension of APP.

Also, going back a few steps in this thread, Dan, you suggested that you
would need an arbitrary number of customer/purchase-order collections.
What I want to do is define a single customer collection and a single
purchase-order collection, banking on the fact that a feed can contain a
subset of the entire collection.  The place I get stuck is that APP
seems to only define a single way of subsetting a collection - through a
linearly ordered list where subsets are first, next, previous and last.
What you need here is a generalized way of identifying subsets of a
collection. Of course, even with that we still need a way of associating
that subset (or purchase orders) with the appropriate entry (customer) -
probably a <link>.

Cornelia


-----Original Message-----
From: James M Snell [mailto:jasnell@gmail.com] 
Sent: Tuesday, September 25, 2007 11:23 AM
To: abdera-user@incubator.apache.org
Subject: Re: Modeling Collections of Collections

Yep... the point I was going for was that nesting app:collection within
application specific extensions generally ties that solution to that
application.  I am very much in favor of coming up with more
generalizable solutions, introducing as few vendor or app specific
extensions as possible.

The rel attribute idea is very interesting and would probably work well.
 I like it :-)

- James

Brian Moseley wrote:
> On 9/25/07, James M Snell <jasnell@gmail.com> wrote:
>> No, but that's a very application specific thing to do; if you're
sure
>> others will be able to figure out what you're doing, then it's fine.
> 
> so is nesting a collection inside an entry. either way, the writer of
> a client will have to be told that the feed includes something
> non-standard. dan's suggestion makes it explicit.
> 
> dan, what about a rel or name attribute on the collections to
> distinguish them apart?
> 
> <atom:entry>
> ...
> <app:collection rel="purchaseOrders" .../>
> <app:collection rel="contacts" .../
> </atom:entry>
> 

Mime
View raw message