Re: Aggregation: simple proposal

On 17 Jan 2013, at 14:11, John Arwe <johnarwe@us.ibm.com> wrote:

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

I think I fixed all your points above. It should be a lot more readable now I hope.

> Best Regards, John
> 
> Voice US 845-435-9470  BluePages 
> Tivoli OSLC Lead - Show me the Scenario 
> 

Social Web Architect
http://bblfish.net/