Re: Aggregation: simple proposal

I think there are different ways aggregations could be added to LDP, and 
extending containers is definitely one possibility. I think Ashok for 
instance suggested at some point that we simply add a property to indicate 
the type of collection you are dealing with. I didn't mean to rule out 
this possibility.

But even if that's the way we decide to go eventually I believe the 
terminology I propose will make talking about this easier.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group


"Wilde, Erik" <Erik.Wilde@emc.com> wrote on 01/17/2013 01:41:59 PM:

> From: "Wilde, Erik" <Erik.Wilde@emc.com>
> To: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>, 
> Cc: John Arwe/Poughkeepsie/IBM@IBMUS, Arnaud Le Hors/Cupertino/IBM@IBMUS
> Date: 01/17/2013 01:42 PM
> Subject: Re: Aggregation: simple proposal
> 
> hello all.
> 
> On 2013-01-17 20:13 , "Arnaud Le Hors" <lehors@us.ibm.com> wrote:
> >Now, given that: 
> >1) the current draft uses the term container
> >2) per resolution of issue-25 at our F2F1 the spec is to be revised to
> >clarify that containers are about composition
> >We really only need a term for the new type of container. So, I 
suggest:
> >1) we use the term container when we mean to talk about composition,
> >strong composition, etc.
> >2) we use the term aggregation when we want to talk about aggregation. 
:-)
> >3) we stop referring to all other terms and variations involving weak 
and
> >strong
> >4) if needed, we use the term collection as a higher level term to 
refer
> >to both types: containers and aggregations
> >I see no problem with ending up with a spec that talks about resources
> >(LDPR), containers (LDPC), and aggregations (LDPA).
> 
> totally agreed that firm terminology is a good thing. but there's no 
need
> to assume that we need different protocol "parts" for both things. in
> atompub, there is no separation of containers, there is only one
> container, and what you POST determines whether it's self-contained or
> not. if the POSTed resource contains all data (<content>...</content> in
> XML), it's what we now call "composition". if the POSTed resource 
contains
> a link to "external content" (<content src=""/> in XML), it's what we 
now
> call "aggregation". i think that this is a good way of handling these
> variations, but it's certainly not the only one. in case we're going 
this
> way, there would only be one type of container, and the data model for
> members would optionally allow a link to external member content. it's a
> simple solution and works well. the beauty is that the server doesn't 
even
> need to care; it's blindly storing what you POST to it. only clients
> GETting a resource need to know that for a linked resource, they also 
need
> to GET the linked content to get the full member information.
> 
> cheers,
> 
> dret.
>