You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@abdera.apache.org by Dan Diephouse <da...@mulesource.com> on 2007/09/15 23:00:38 UTC

Modeling Collections of Collections

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

-- 
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog



Re: Modeling Collections of Collections

Posted by Brian Moseley <bc...@osafoundation.org>.
On 9/15/07, James M Snell <ja...@gmail.com> 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.

oh, that's a good idea. i'd just been using a link to point to the
related collection, as dan suggested.

Re: Modeling Collections of Collections

Posted by Dan Diephouse <da...@mulesource.com>.
This makes a lot of sense. Thanks for the insight,
- 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
>>
>>     


-- 
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog


Re: Modeling Collections of Collections

Posted by James M Snell <ja...@gmail.com>.
It's from the Atompub spec.  It's part of the Service document format.

- James

Chris Berry wrote:
> 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
> 
> 
> 
> 

Re: Modeling Collections of Collections

Posted by Chris Berry <ch...@gmail.com>.
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




Re: Modeling Collections of Collections

Posted by Jan Algermissen <al...@mac.com>.
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
>>>>
>>>>
>>
>>


RE: Modeling Collections of Collections

Posted by Da...@emc.com.
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 <ja...@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>
> 

Re: Modeling Collections of Collections

Posted by James M Snell <ja...@gmail.com>.
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 <ja...@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>
> 

Re: Modeling Collections of Collections

Posted by James M Snell <ja...@gmail.com>.
I've been working on a "feature discovery" extension for the Service
document syntax.  You can find an early prototype impl in the main
extension module.  It provides a basic framework for communicating these
kinds of things.  You would have to develop the means of describing the
specifics but the features draft at least provides a generalize
framework for doing it.

Dan Diephouse wrote:
> Brian Moseley wrote:
>> On 9/25/07, James M Snell <ja...@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.
>>   
> Well this is part of my problem with the whole "RESTful services don't
> need a description language thing". It'd be very nice from a machine 2
> machine point of view if I could have some metadata inside my
> <collection> which goes beyond <accept>, because for anything beyond
> well understood content types like html, images, etc, you're stuck.  For
> instance, I may know that my collection accepts
> "application/atom+xml;type=entry", but:
> 
> 1.How do I know what types of XML content my <entry> might hold. I.e.
> does it contain a <customerInfo> document of the type
> application/vnd.acme.customer+xml? It seems that if you aren't using
> media entries, you have to have the accept set to
> "application/atom+xml;type=entry", no?
> 1a. Should <customerInfo> be included as a direct child of <entry> or
> <content>?
> 1b. If the later is valid, I can set a contentType on <content>. Then
> could I also do <accept>application/vnd.acme.customer+xml</accept?
> 
> 2. How do I relate the mime type to the schema so that the other machine
> can browse to it?
> 
> Ideally I'd like to see something like:
> 
> <workspace>
> <collection>
>   <description mimeType="application/vnd.acme.customer+xml"
> descriptionType="http://foo.bar/relaxNg" href="blah.rng"/>
> </collection>
> </workspace>
> 
>> 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>
>>   
> That could work. I didn't realize that was legal! (although legal !=
> standard ;-))
> 
> - Dan
> 
> -- 
> Dan Diephouse
> MuleSource
> http://mulesource.com | http://netzooid.com/blog
> 

Re: Modeling Collections of Collections

Posted by Brian Moseley <bc...@osafoundation.org>.
On 9/25/07, James M Snell <ja...@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>

Re: Modeling Collections of Collections

Posted by James M Snell <ja...@gmail.com>.
You're in fairly unchartered territory as far as the standards are
concerned, so do what works best for your application, I would just
encourage you to find a way of doing it that can be generalized to other
types of applications.

- James

Dan Diephouse wrote:
> Well, I don't see any other ways around it really. I'm not about to have
> a Collection of Customers which has a Collection which includes Contacts
> and Purchase orders, which in turn are collections.
> 
> What about:
> 
> <link rel="purchaseOrders" href="customer/foo/purchaseOrders"/>
> <link rel="contacts" href="customer/foo/contacts"/>
> 
> You lose the accept info though. So once again, it requires foreknowledge.
> 
> - Dan
> 
> James M Snell 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.
>>
>> - James
>>
>> Dan Diephouse wrote:
>>  
>>> Would it be completely wrong to do something like this?
>>>
>>> <atom:entry>
>>>  ...
>>>  <acme:purchaseOrders>
>>>    <app:collection .../>
>>>  </acme:purchaseOrders>
>>>  <acme:contacts>
>>>    <app:collection ../>
>>>  </acme:contacts>
>>> </atom:entry>
>>>
>>> - Dan
>>> 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 :-)
>>>>
>>>> - 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
>>>>>>>
>>>>>>>                         
>>>>>             
>>>     
> 
> 

Re: Modeling Collections of Collections

Posted by Dan Diephouse <da...@mulesource.com>.
Well, I don't see any other ways around it really. I'm not about to have 
a Collection of Customers which has a Collection which includes Contacts 
and Purchase orders, which in turn are collections.

What about:

<link rel="purchaseOrders" href="customer/foo/purchaseOrders"/>
<link rel="contacts" href="customer/foo/contacts"/>

You lose the accept info though. So once again, it requires foreknowledge.

- Dan

James M Snell 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.
>
> - James
>
> Dan Diephouse wrote:
>   
>> Would it be completely wrong to do something like this?
>>
>> <atom:entry>
>>  ...
>>  <acme:purchaseOrders>
>>    <app:collection .../>
>>  </acme:purchaseOrders>
>>  <acme:contacts>
>>    <app:collection ../>
>>  </acme:contacts>
>> </atom:entry>
>>
>> - Dan
>> 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 :-)
>>>
>>> - 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
>>>>>>
>>>>>>             
>>>>>>             
>>>>     
>>>>         
>>     


-- 
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog


Re: Modeling Collections of Collections

Posted by James M Snell <ja...@gmail.com>.
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.

- James

Dan Diephouse wrote:
> Would it be completely wrong to do something like this?
> 
> <atom:entry>
>  ...
>  <acme:purchaseOrders>
>    <app:collection .../>
>  </acme:purchaseOrders>
>  <acme:contacts>
>    <app:collection ../>
>  </acme:contacts>
> </atom:entry>
> 
> - Dan
> 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 :-)
>>
>> - 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
>>>>>
>>>>>             
>>>     
> 
> 

Re: Modeling Collections of Collections

Posted by Dan Diephouse <da...@mulesource.com>.
Would it be completely wrong to do something like this?

<atom:entry>
  ...
  <acme:purchaseOrders>
    <app:collection .../>
  </acme:purchaseOrders>
  <acme:contacts>
    <app:collection ../>
  </acme:contacts>
</atom:entry>

- Dan
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 :-)
>
> - 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
>>>>
>>>>     
>>>>         
>>     


-- 
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog


Re: Modeling Collections of Collections

Posted by James M Snell <ja...@gmail.com>.
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 :-)

- 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
>>>
>>>     
> 
> 

Re: Modeling Collections of Collections

Posted by Dan Diephouse <da...@mulesource.com>.
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
>>
>>     


-- 
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog


Re: Modeling Collections of Collections

Posted by James M Snell <ja...@gmail.com>.
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
>