Re: issue-89 proposals

Argh, made a mistake, sent too soon :'(

Alexandre.

On 01/06/2014 10:41 AM, Alexandre Bertails wrote:
> On 12/18/2013 01:45 PM, John Arwe wrote:
>>> 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.
>
> Ok.
>
>>
>>
>>>> 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;
>
> Yes. Membership was already defined and we didn't want to touch that
> definition. I chose Containment especially because it captures what we
> want, and there is no collision with something already in the spec.
>
>> 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.
>
> That just means that there is no dependency 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.
>
> True, it does double the number of triples at the conceptual level. The
> approach is really to play with something along PROPOSAL 5 to opt-out in
> the case of too many triples.
>
>>
>> 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)?
>
> Containment is closely related to the LDP interactions. If you choose to
> interact through other ways -- touching the underlying database for
> example -- then you don't really know what documents were created anyway
> (membership does not answer that question, and that's ok I believe).
>
>>
>>
>>>> (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.
>
> That's exact.
>
>>
>>> ... 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.
>
> Very important point, indeed.
>
>>
>> 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
>>
>>
>

Received on Monday, 6 January 2014 15:42:01 UTC