Repository navigation
Text editing operations #25
Description
It is an alternative proposal to #6 that defines text editing operations similarly to how structural changes are defined with additional operations: add-text, remove-text, replace-text, move-text, copy-text, test-text.
Overloading the existing operations as #6 suggests could be confusing.
See https://github.com/epoberezkin/extended-json-patch#text-editing-and-testing for the details
Activity
mitar commentedon Oct 12, 2019
I do not like that it relies on text lines. I would prefer absolute offsets in characters from the beginning of text.
epoberezkin commentedon Oct 13, 2019
The idea is to support both.
mitar commentedon Oct 13, 2019
I see, I missed that it can be either, but I still think that having to support both makes merging algorithms more complicated than necessary. You really just want to convey information about what the diff/patch is, too many options how to represent that means multiple ways you have to support. Moreover, for lines, it is unclear what happens if one uses different line endings.
I also do not think a new set of operations are necessary, see my #28 proposal.
epoberezkin commentedon Oct 27, 2019
Exactly because different systems use different line endings, using line and column to address position in the text would lead to consistent operations across multiple systems.
Using index can lead that the same operation would result in different outcome, unless care is taken to use the same line endings.
So the idea of the proposal is to use line/column for multi line texts, and use index for string/byte sequence.
mitar commentedon Oct 27, 2019
I disagree here. But maybe because we have different model of what JSON patch is. To me it is a diff between two known versions of JSON. Those JSON files have exactly known content, with exactly known string values, known encoding of newlines and so on. And then you represent the change from one of them to the other.
On the other hand, it seems you are seeing it more like a program, with limited semantics, saying more something alongside "find X line, add after it another line". Which can work on multiple different JSONs, with different content for the text you are trying to patch, and different line endings as well. To me, such use of JSON patch is problematic because then we are inventing a domain specific language for modifications to JSON documents. And how far do we want to go? Re-invent MongoDB query syntax? Some other proposals in this repositories are going in that direction as well (more array operations, etc.). I think this goes against the simplicity of the JSON patch.
I do recognize that maybe some standardized full-query language like MongoDB provides would be useful for some use cases, but I think we would then need two standards, one to represent fixed diff between two known versions, and one to represent update queries against a set of potential JSON documents.