W3C home > Mailing lists > Public > public-ldp-wg@w3.org > November 2014

Re: Updated LD Patch specification

From: Alexandre Bertails <alexandre@bertails.org>
Date: Mon, 24 Nov 2014 14:30:18 -0500
Message-ID: <CANvn8ky_9Yoxw7fF8Hw3_SyJE1-h1+FRUthc3N6zXqCRRTQcBw@mail.gmail.com>
To: Steve Speicher <sspeiche@gmail.com>
Cc: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>, Arnaud Le Hors <lehors@us.ibm.com>, Tim Berners-Lee <timbl@w3.org>, Sandro Hawke <sandro@w3.org>
On Mon, Nov 24, 2014 at 2:10 PM, Steve Speicher <sspeiche@gmail.com> wrote:
> Some additional feedback on the latest editor's draft last modified
> 23-November-2014 [1].
>
> Overall a great improvement, one red flag for me is that the entire
> document contains 13 RFC2119 conformance keywords, that seems very
> low.  For an example, LDP's last publication contained about 103.
> Below are some specific comments.  The biggest issues are the keywords
> and the different between Add and Delete when they can ignore an
> operation (one case it is success and the other failure).
>
> <#introduction> Seems it would be good to use some LDP terminology
> here, for example:
> "LD Patch language (or LD Patch document) defines a list of operations
> to be performed against a Linked Data resource"
> adding " (also known as LDP RDF Source [[LDP]])".

Agreed.

>
> <#list-manipulation-examples> Suggested improvements here.  I don't
> have much background on using this slicing approach, so I tried to
> learn it from the examples but I found myself having a little trouble,
> I could imagine others would.  It would help to see the result, have
> each example use the output from the previous as input to the next.

Agreed seeing results. But I don't think that keeping a state for the
previous operations help for readability: it's better to always reuse
the same input.

>
> <#semantics> (intro paragraph) Again the terminology is near LDP-RS
> but different, the "target graph" is the "LDP RDF Source" or "target
> LDP-RS".  Not sure your terminology should completely change to LDP's
> but I think there should be some connection made.

Yes, this is a good remark.

>
> <#semantics> Section is not marked "non-normative" but in all 3.1-3.3
> sections I only see 1 statement with a RFC2119 conformance keyword,
> 3.4 has a list of them though.  Is this intentionally?  ReSpec only
> recognizes 13 RFC2119 keywords in the whole document, that seems low.

Well, there are only 2 kinds of errors: static/syntactic, or at
runtime. So it either goes well, or if it doesn't go well, then
<#error-handling> tells you what you must do.

I know it doesn't like a lot, but not that much can happen in LD Patch.

>
> <#bind-statement> Is "RDF Term" the same thing as "RDF terms" from
> http://www.w3.org/TR/rdf11-concepts/#dfn-rdf-term ?  Assume so, would
> be good to put a reference in and be consistent in style (it doesn't
> use uppercase T in terms).

I'll look into it.

>
> <#delete-statement> I wonder about this requirement:
> "It fails if one of those triples does not exist in the target graph." and later
> "If a Delete attempts to remove a non-existing triple, then a HTTP 422
> (Unprocessable Entity) error status code must be returned."
> I wonder why this requirement exists?  I could see cases where I might
> want to "blind delete" triples, for example I'm delete'ing a web
> resource and I want to bulk a number of other resources that link to
> it (i.e. contain triples with known pattern).  Given the quoted
> requirement, I would first need to GET every resource that I believe
> could have a link-to triple, then formulate the PATCH and submit the
> patch.  Reading PATCH (RFC5789) I don't see where this requires this,
> if if the operation "Delete" is successful the graph doesn't contain
> the triple.  This seems like it doesn't align with the fact that Add
> MUST NOT fail if the graph already contains the triple.

That is a very good remark that Pierre-Antoine, Andrei, and I debated
*a lot* :-) Note that it applies to Add as well, i.e. is it ok to add
an already existing triple?

We know that we want the default to be non-silent on that kind of
errors (for Delete at least as Add doesn't fail in the dual case).
That was a requirement we had from different people, including TimBL
re: silent fail is bad.

That being said, we also agree that "blind delete" is a very valid
use-case. We thought about adding a directive in LD Patch so that one
can change the default. We didn't do it, because 1. that would have
been an arbitrary choice from us without having other people bringing
the use-case, while we were trying to deliver a stable specification,
and 2. because this could have been easily added as a _conservative
extension_ in a second version.

But now that you brought it, and because it is easy to add, and
because we have one more week to do so, we can think about doing it. I
already know that Andrei and Pierre-Antoine are totally fine with this
addition.

So the question is now for Arnaud: is it ok for me to proceed and make
such an addition to the spec?

Alexandre

>
>
> [1]: https://dvcs.w3.org/hg/ldpwg/file/cd2b89e3cdc8/ldpatch.html
>
> Thanks,
> Steve Speicher
> http://stevespeicher.me
>
>
> On Fri, Nov 21, 2014 at 5:13 PM, Alexandre Bertails
> <alexandre@bertails.org> wrote:
>> All,
>>
>> We have updated the LD Patch specification [1].
>>
>> We may have few fixes over the week-end, but we believe it is now
>> stable and ready for review. You can find a summary of the changes at
>> the end of the document.
>>
>> Most notably:
>>
>> * this includes TimBL's proposal to accept Turtle in Add statements.
>> * ISSUE-100 is *pro-actively resolved*, please see [2]
>> *  we believe that comments from TimBL, Steve, and Sandro are addressed.
>>
>> Cheers,
>>
>> Alexandre
>>
>> [1] https://dvcs.w3.org/hg/ldpwg/raw-file/ldpatch/ldpatch.html
>> [2] http://lists.w3.org/Archives/Public/public-ldp-wg/2014Nov/0064.html
Received on Monday, 24 November 2014 19:30:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:59 UTC