Re: Proposal to close ISSUE-17: changesets as a recommended PATCH format, as is

On 25 May 2013, at 03:33, Cody Burleson <cody.burleson@base22.com> wrote:

> Looking through the history of this issue and chewing on it (out loud)...
> 
> 1. David Wood has suggested "I suggest yes.  However, they should probably become a separate Note or Rec in parallel.)
> 2. Ashok has said, "I could see if we need to develop a complex patch document format that we should discuss the best way to make that happen as it may be too much for our WG as-is."
> 3. TurtlePatch has been referred to (see http://www.w3.org/2001/sw/wiki/TurtlePatch), but this document appears to be exactly as it claims: just "a sketch" of a spec. It raises the the notion of a need - that's about it.
> 4. The Talis ChangeSets have also been referenced and this is the most thorough set of examples of real-world useful stuff I could find. Could be a good starting point, indeed.
> 5. Very little of the history of ISSUE-17 makes useful contribution in such that it looks like something concrete and agreeable even started to come out of it. Almost half the history, in fact, spins off into a discussion about something else entirely. So, unless Sandro's got something surprising in the oven, we've cooked up very little at all.
> 6. Some personal notes from Tim-BL on RDF diff (a little dated, perhaps, but interesting): http://www.w3.org/DesignIssues/Diff

There is also SPARQL Update narrowed down for our needs. It could be easy enough to do that and
the language is a standard. If we can't narrow it down I imagine many LDP implementations will offer
that by default, as most RDF suites have SPARQL update implemented allready.


> 7. RFC5789 for HTTP PATCH, states:
> 
> There is no guarantee that a resource can be modified with PATCH. Further, it is expected that different patch document formats will be appropriate for different types of resources and that no single format will be appropriate for all types of resources.  Therefore, there is no single default patch document format that implementations are required to support.  Servers MUST ensure that a received patch document is appropriate for the type of resource identified by the Request-URI.
> 
> MY VOTE: 
> I think the spec is good AS-IS about PATCH, but that we should make a commitment to address the subject in the Deployment Guide so that there is at least a recommended approach that works or, at minimum, a reference to the most reasonable approaches we can find published. I favor starting with a straw-man approach and letting a standard emerge from that organically.
> 
> I've been cautious to provide too much input to a lot of these discussions because I'm the kind of person that has trouble applying this stuff in the head-space alone. I have to run these things through the gauntlet of working software code before I know what's good or what's a royal pain. That work is slow-gowing for me, but maybe in the mean-time I can apply value by culling through our history and helping to get this Deployment Guide structured or something? If Sandro needs help concertizing something around PATCH for the Deployment Guide, if I could cull through our history and start structuring the deployment guide overall, or whatever - let me know. I need to try my hand at being useful here, so, please feel free to direct me. An empty coffee pot, perhaps, or some toilet that needs scrubbed...
> 
> 
> - Cody
> 
> 
> On Fri, May 24, 2013 at 4:43 PM, Arnaud Le Hors <lehors@us.ibm.com> wrote:
> Hi all, 
> 
> We've all dreamt about it but I think it's time for us to accept that we won't be able to address this issue this time around. Sandro has been exploring different solutions but this is still work in progress. 
> 
> We have to be realistic. There is no way we can have a document go through the necessary scrutiny for us to formally reference it in the LDP spec. 
> 
> So, I'm proposing we close this issue and put it on the wish list. This means that PATCH will keep not specifying any particular patch format in the spec. 
> 
> If Sandro's efforts lead anywhere we can always add a reference to the Deployment Guide as a stop gap. 
> 
> Best regards.
> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
> 
> 
> 
> -- 
> Cody Burleson
> Enterprise Web Architect, Base22
> Mobile: +1 (214) 702-6338
> Skype: codyburleson
> Email: cody@base22.com
> Blog: codyburleson.com
> 
> <base22.gif>
> 
> Check my free/busy time.
> 
> 

Social Web Architect
http://bblfish.net/