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.

Received on Thursday, 17 January 2013 21:42:51 UTC