Re: issue-89 proposals

[real answer that one, sorry]

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

>
>
>>> 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 very closely related to the LDP interactions. If you
choose to interact through other ways -- eg. touching directly 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 think what's important here is to get the logic right -- if a triple
is part of the Named Graph (membership, containment), then return it
by default in the GET -- and then to define the opt-out mechanism as
an optimisation (PROPOSAL 5).

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

I'm not sure to understand that last comment. Can you clarify?

Regards,
Alexandre.

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

Received on Monday, 6 January 2014 16:05:50 UTC