On Sat, Mar 31, 2012 at 9:34 AM, Julian Reschke <julian.resc...@gmx.de> wrote: > On 2012-03-27 11:47, Stefan Guggisberg wrote: >> >> On Fri, Mar 23, 2012 at 6:04 PM, Julian Reschke<julian.resc...@gmx.de> >> wrote: >>> >>> I have updated the Wiki page with an IETF ABNF variant of the JSOP Diff >>> syntax. >>> >>> Open questions are: >>> >>> - JSON Patch (the IETF spec) allows set operations with objects; JSOP >>> Diff >>> didn't need it yet (as it's for overwriting properties); we probably >>> should >>> allow it in order to remove the mismatch (same for "test") >> >> >> agreed >> >>> >>> - are pointers escaped the same way as in JSON Pointers or not? As we do >>> not >>> need "/" in names, we probably can get away without escaping, but then >>> JSOP-Diff wouldn't be able to express all JSON-Patch documents >> >> >> would that be a problem? if possible i'd rather keep it simple and not >> support the '^' escaping. > > > We just need to be aware of the issue/mismatch and document it. I'm ok with > doing it this way. > > >> OTOH if it proofs to be a real iterop issue it might perhaps be worth >> the effort. > > > The question here is what needs to interop with that. > > If this format is used purely inside Oak, we don't have to deal with it. > > If this is positioned as a generic patch format for JSON, we do have to. > > It would be good to finally decide on where we want to go with this format.
agreed. while i like the idea of JSOP diff becoming a generic patch format for JSON i don't think that it's worth the extra headaches. on second thought i am now convinced that we should not support JSON Pointer (i.e. the escaping of forward slashes). i imagine such paths could/will be used in URLs. paths like "/foo/bar/yes^/no" would certainly cause problems. WDYT? cheers stefan > > >>> >>> - extensibility / metadata are not addressed yet >>> >>> As a next step we should document the mapping between these two formats >>> (while noting the remaining differences). That way we can define the >>> semantics of a JSOP-Diff instance in terms of JSON Patch, we should be on >>> the IETF Standards Track in the not-to distant future. >> >> >> +1, excellent! >> >> cheers >> stefan > > > Best regards, Julian