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

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

* <http://base22.com>*
*
*
*Check my free/busy
time.<http://www.google.com/calendar/embed?src=cody.burleson%40base22.com&ctz=America/Chicago%20>
*