abdera-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Berry <chriswbe...@gmail.com>
Subject Re: Modeling Collections of Collections
Date Tue, 25 Sep 2007 13:54:59 GMT
I suppose I should know this, but is app:collection an extension to  
the spec??
http://www.atomenabled.org/developers/syndication/atom-format-spec.php

atomEntry =
    element atom:entry {
       atomCommonAttributes,
       (atomAuthor*
        & atomCategory*
        & atomContent?
        & atomContributor*
        & atomId
        & atomLink*
        & atomPublished?
        & atomRights?
        & atomSource?
        & atomSummary?
        & atomTitle
        & atomUpdated
        & extensionElement*)
    }

Thanks,
-- Chris


On Sep 24, 2007, at 2:40 PM, Jan Algermissen wrote:

>
> On 24.09.2007, at 21:30, James M Snell wrote:
>
>> Well, the idea is that there is a one-to-one mapping from an entry  
>> to a
>> collection.  So for each collection you have, you'll have one  
>> entry.  I
>> don't have any suggestions for doing anything else :-)
>
> I think that a subcollection is fundamentally different from an  
> entry in a collection and that only the ubiquity of file systems  
> makes us think the two concepts somehow share a common base. IMHO,  
> the existence of a subcollection allways represents an act of  
> categorization and segmentation of the parent collection which is  
> lost if we simply represent subcollections as entries.
>
> I have not yet had any time whatsoever to flesh this out, but I  
> suggest an extension element of <feed>, such as <subcollections>  
> and inside that, a normal feed with entries can be used to  
> represent the sub collections. This would preserve the semantic,  
> that the parent collection is segmented.
>
> Sorry that this is so vague, but maybe it helps somehow.
>
> Jan
>
>
>
>>
>> - James
>>
>> Dan Diephouse wrote:
>>> That seems to work well for one collection. What do you do if you  
>>> have
>>> multiple collections? For instance a Customer with a collection of
>>> purchase orders and a collection of contacts? How might I  
>>> distinguish
>>> between these two collections in the entry? Any other wisdom to  
>>> share? :-)
>>>
>>> Cheers,
>>> - Dan
>>>
>>> James M Snell wrote:
>>>> We had this problem in the Lotus Connections Activities  
>>>> component.  Each
>>>> user has a collection of Activities. Each Activity is itself a
>>>> Collection.  There is a top level My Activities collection.   
>>>> Each entry
>>>> represents an Activity.  Those entries contain an app:collection  
>>>> element
>>>> that points to the activity collection uri, e.g.
>>>>
>>>> <entry>
>>>>   ...
>>>>   <app:collection href="...">
>>>>     <app:accept>application/atom+xml;type=entry</app:accept>
>>>>     ...
>>>>   </app:collection>
>>>>   ...
>>>> </entry>
>>>>
>>>> This approach has worked very well for us.
>>>>
>>>> - James
>>>>
>>>> Dan Diephouse wrote:
>>>>
>>>>> I am pondering how to model collections of collections with APP  
>>>>> for more
>>>>> non-blogging oriented applications. For instance, lets say I  
>>>>> have a
>>>>> collection of customers, which have a collection of purchase  
>>>>> orders. I
>>>>> can easily model the customers as a collection. Each entry  
>>>>> represents a
>>>>> customer.
>>>>>
>>>>> But then what do I do about the purchase orders? The best  
>>>>> solution that
>>>>> I can come up with is that I have another collection for each  
>>>>> customer.
>>>>> Each entry in the collection would then be a purchase order.  
>>>>> However,
>>>>> this has two downsides:
>>>>> 1. There is no great way to go directly from the customer to the
>>>>> purchase order collection. The best solution I've come up with is
>>>>> something <link rel="purchase-orders"
>>>>> href="service/customer-foo/purchase-orders"/>. Not sure if  
>>>>> thats a Good
>>>>> Thing or not.
>>>>> 2. Now my workspace has a gazillion customer/purchase order  
>>>>> collections
>>>>> in it. I probably don't want to list those all out as that  
>>>>> would take
>>>>> forever. The best solution that I've come up with here is to  
>>>>> just not
>>>>> list them and make item #1 be the best way to find the collection.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> - Dan
>>>>>
>>>>>
>>>
>>>
>

S'all good  ---   chriswberry at gmail dot com




Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message