Re: issue-89 proposals

> I still don't know how PATCH works with resource creation.

RFC 5789 section 2 says: If the Request-URI does not
   point to an existing resource, the server MAY create a new resource,
   depending on the patch document type (whether it can logically modify
   a null resource) and permissions, etc.
AFAIK, LDP does not MUST NOT that.  So, by its silence, it is allowed and 
5789 says how it works.


> > 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..."
> 
> This is just 5.4.1.

I don't understand how you can say that coherently.  Proposal 3 talks 
about containment triples which are not in ANY draft at this point.  Heck, 
the word "containment" is nowhere in the *entire* editor's draft (to pick 
on the one I searched).  I could assume you're after an analogy with 
membership triples; of course "triple" does not occur in 5.4.1-5.4.6 of 
the editor's draft either and proposal 3 says that it does not [bold not] 
build on membership.  So I'm back to frowny-face.

Back to the original question: is the wording in proposal 3 intended to 
convey a MUST requirement, or some other 2119 keyword (which)?
Some of us know that we intend to use LDP (in what we call the 
DirectContainer variety, as of issue-89's resolution) for collections with 
members in the 10^5 to 10^6 range (in terms of what's been tested already, 
millions of members, but that limit is implementation-based not 
conceptual), and we need to know if this proposal doubles the number of 
triples required in some representations (and if so, in which of them and 
whether or not supporting them is required).  We need to be clear on the 
implementation implications of what we vote on.

Since we're defining containment, and proposal 3 says that it does not 
[yours: bold not] build on membership, I need to ask about a case 
corresponding to the (membership) case covered in 5.4.2, i.e. creation via 
means other than what LDP defines.  If LDPC members are created through 
those other means, does your proposal require (MUST) the addition of 
corresponding containment triples?  Does prohibit (MUST NOT) that? 
Something in between (what)?


> > (2) clients desiring to avoid both the membership and containment 
triples
> > follow a link header to something analogous to the 
non-member-properties
> > resource
> 
> If we keep that one, yes.

It sounds like a more accurate version would be: Proposal 5 as currently 
written says this is no longer possible, but you would be open to revising 
it to add what it proposes alongside what-currently-is instead of 
replacing what-currently-is.  Fair enough.

> ... The only feedback was more or less "we don't care about the 
> containment triples and are only interested in the membership triples, 
> we just want something that reflects that".

That may be true, but without the context of the question being responded 
to and the responders' assumptions, I want to be clear about anything 
we're removing so people have a chance to re-evaluate *before* all the 
drafting whether or not what's left satisfies their needs.

The non-member resource exists today as a way by which clients can get at 
a certain subset of the triples without (assumption alert!) being 
"flooded" by the much more numerous membership triples.  If we now add 
still more triples (containment) that those original cases also don't care 
about (since the use cases allegedly were satisfied without any 
containment triples, this is true for those original cases) and that 
"commonly" number on par with membership triples, we're making the 
original problem worse (even as we improve others - yin/yang).

I have a hard time believing we can just stuff a bunch of extra triples 
into what (under 5 as written, given your reply to my clarifying question) 
becomes the only LDP-defined way to avoid the (possibly numerous) 
membership triples without knocking over someone's apple cart.


Best Regards, John

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