Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Text editing operations #25

Open
epoberezkin opened this issue Jul 14, 2019 · 5 comments
Open

Text editing operations #25

epoberezkin opened this issue Jul 14, 2019 · 5 comments

Comments

@epoberezkin
Copy link

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

@mitar
Copy link

mitar commented 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
Copy link
Author

The idea is to support both.

@mitar
Copy link

mitar commented 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
Copy link
Author

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

mitar commented 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants