issue-89 proposals

Proposal 3: omits PATCH, which allows creation.  As with issue 90 proposal 
2, probably true that if you were to add that PATCH works "mostly" like 
POST, it's covered.


Proposal 3: "A successful POST on the LDPC results in a new containment 
triple, the containment object being the URL returned in the Location 
header. Note: this is true for any LDPR, including an LDPB. "  Is the 
intent that this be a MUST or a MAY?  As phrased I would guess it's a 
MUST, in the sense of "If an LDPC supports creation of members via LDP, 
then it MUST..."


Proposal 5:  Am I correctly gathering that your intent is to Replace the 
current non-member resource with the non-containment resource, as "change" 
would imply?  Versus adding something new alongside what-currently-is? 

Proposal 5:  Am I correctly gathering that your intent is that all of the 
following are true?
(1) retrieval of a container gets a client "all" (modulo paging 
discussions) the containment, membership, and non-member properties as a 
minimum
(2) clients desiring to avoid both the membership and containment triples 
follow a link header to something analogous to the non-member-properties 
resource
(3) clients desiring to avoid only the containment triples follow a link 
header to something analogous to the non-member-properties resource 
unioned with membership triples
(4) any additional triples like member-properties triples can be added to 
any of 1-3 at the server's discretion
Implying there is no way for a client to see only the non-member 
properties unioned with the containment triples.  Which I'm fine with, if 
that's your intent.


Best Regards, John

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