- From: Robin Berjon <robin@w3.org>
- Date: Thu, 06 Aug 2015 15:13:04 +0200
- To: Hallvord Reiar Michaelsen Steen <hsteen@mozilla.com>, Anne van Kesteren <annevk@annevk.nl>
- CC: WebApps WG <public-webapps@w3.org>
Hi Hallvord, I don't have a specific opinion on where what should be done, speaking personally I certainly don't have an issue with XHR being at the WHATWG, but just some notes below in case it helps. On 06/08/2015 14:07 , Hallvord Reiar Michaelsen Steen wrote: > And that is mostly my fault. I intended to keep the W3C fork up to date > (at least up to a point), but at some point I attempted to simply apply > Git patches from Anne's edits to the WHATWG version, and it turned out > Git had problems applying them automatically for whatever reason - > apparently the versions were already so distinct that it wasn't > possible. Yes, once differences grow too much, even if you make use of cherry-picking, at some point there isn't much that git (or diff/patch) can do to merge two documents that are too far apart. > Since then I haven't found time for doing the manual > cut-and-paste work required, and I therefore think it's probably better > to follow Anne's advice and drop the W3C version entirely in favour of > the WHATWG version. I still like the idea of having a "stable" spec > documenting the interoperable behaviour of XHR by a given point in time > - but I haven't been able to prioritise it and neither, apparently, have > the other two editors. Depending on how involved the differences between L1 and the LS are, one option is to do this with code. If L1 is a subset and the subsetting doesn't require editing things mid-sentence (e.g. just dropping sections and a few odds and ends) then you can simply keep pulling the LS and apply code that filters out what you don't want. -- Robin Berjon - http://berjon.com/ - @robinberjon
Received on Thursday, 6 August 2015 13:13:12 UTC