Extend array operations to also work on strings

[mitar]

As an alternative to #6 and #25 I would propose that operations are allowed to index into strings as well. This would allow one to modify parts of a string instead of sending the whole value over. Moreover, internally, strings are often seen as something you can index already, or are even arrays of characters.

So for a JSON like:

{"value": "foobar"}

A patch like:

[
  {"op": "replace", "path": "/value/0-3", "value": "no"}
]

Replacing first three characters with "no' and resulting in:

{"value": "nobar"}

So upper limit would be exclusive. You could also specify "2-" to select all characters from the 3rd character to the end.

I would not introduce a whole new set of string operations. And also do note that such pointer is uniquely determined given a type of the value at the path. So if it points to an array, 0-3 index into the array (for now I would leave such index invalid for arrays, but that could be a separate discussion), if it points to a string it index into the string. And if there is an object, it is simply a 0-3 property of the object.

[ucarion]

(Let me know if you'd prefer this question be posed in json@ietf.org)

What, in your view, should indexing into strings mean here? Are we indexing into an array of codepoints? Bytes (presuming some particular representation)? Something else?

In other words, what does "character" mean here?

[mitar]

(Let me know if you'd prefer this question be posed in json@ietf.org)

I think it is good here, I posted a link there to this issue, so I think we can move conversation herje.

What, in your view, should indexing into strings mean here? Are we indexing into an array of codepoints? Bytes (presuming some particular representation)? Something else?

I think that JSON standard already discusses string comparisons by code units, so I think this indexing into strings should be done by code units as well.