Re: Aggregation: simple proposal

Henry, some questions on the revisions.

1: "collection" seems to be used inconsistently.  We'd likely need to 
declare a meaning on your page and paraphrase the emails in Q&A (at least) 
in order to align them with its language.  I have the impression mostly 
that unqualified-collections is a general term used to encompass both 
strictly compositional collections and aggregation-al collections 
(sometimes also called strong and weak collections or strong and weak 
containers).  I propose that we consistently use collections as the 
general term (encompassing both composition and aggregation), consistently 
use a distinct single term for compositions, and do likewise for 
aggregations.  I care less about the terms chosen than the consistent use 
aspect.  I want to be sure that when term X is used that author and reader 
have only one choice of semantic to apply to that term, even if for now 
that is true only within the context of each proposal.  It *probably* 
would be less disruptive to use Container for the compositional term, 
given our liberal use of ldpC in emails, although it might be more 
clarifying to intentionally choose an entirely different term so we're 
less apt to use it by accident.  Example of the existing inconsistencies: 
"existing container: http://localhost:9000/2012/ ... Let us start with an 
empty collection [JA: vs container]. ... Create a new aggregation inside 
the container [JA: vs collection] ... Create a aggregation container named 
aggregate1 inside the same collection."

2: shouldn't the aggregate1 create response be 201?

3: (delete agg) "Note that in both cases it is clear that as opposed to 
LDPC's this does not delete any of the resources contained in the 
Aggregation Container. "  I don't think it is clear *from what is shown". 
It would be fair as an assertion of the proposal.  To be clear I think 
you'd need to show the before-aggregate1-state [i.e. what a subsequent GET 
would return, for EACH of the resources involved, perhaps by pointing to 
an earlier copy, but "always" clearer to be pedantic and reproduce it in 
full], the request [already here], and the after-aggregate1-state [i.e. 
what a subsequent GET would return, for EACH of the resources involved]

4: (delete alt 1) HTTP/1.1 410 OK looks... inconsistent ;-)

5: (delete alt 2) "other things inside the collection that should be kept" 
... by "other things inside the collection" do you mean what the spec 
calls "non-member properties"?  It appears so.


Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario