Hi, On Thu, Mar 22, 2012 at 4:53 PM, Stefan Guggisberg <stefan.guggisb...@gmail.com> wrote: > On Thu, Mar 22, 2012 at 4:22 PM, Jukka Zitting <jukka.zitt...@gmail.com> > wrote: >> Can we turn that into a harder API contract, i.e. one that should hold >> true for any MK implementation? If not, we need to define the >> boundaries of what oak-core can expect the MK to store reliably. We >> don't need the answers right away, but ultimately this needs to be >> defined for us to properly resolve OAK-33. > > ack and agreed. i am fine with specifying a harder api contract something > along the lines of 'values are treated as opaque character sequences'.
Sounds good. >> A related question, will a value like "\u0058" be considered equal to >> "X" for example when merging concurrent changes? What about [ ] vs. [] >> (i.e. extra whitespace within an empty array)? > > hmm, now it gets tricky... if the mk treats values as opaque character > sequences > it would consider the above examples non-equal. we'll have to see whether > that's an issue. if it turns out to be an issue we'll have to provide > for smarter merge-logic and perhaps some basic normalization (e.g. > removing ws within arrays). I suppose we can handle that on the oak-core level, i.e. make sure that any values sent to the MK are always in normalized form. BR, Jukka Zitting
