Re: Updated LD Patch specification

On Mon, Nov 24, 2014 at 2:30 PM, Alexandre Bertails
<alexandre@bertails.org> wrote:
> 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.

Sorry, I responded too quickly on that one.

LD Patch enables PATCHing for LDP-RS as defined in LDP, but it is not
restrained to them.

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

Done.

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

Same remark than above.

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

Good catch. I have made the change to all occurrences of RDF Term.

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

Still have to work on that one.

Cheers,

Alexandre

>
> 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 Tuesday, 25 November 2014 03:52:17 UTC