Unify JSON Range Units

[mitar]

To resolve #29 and #23 @toomim and I discussed that he should make an alternative proposal for a range unit (a fork) which has slightly different approach:

• It uses . instead of / to represent the path.
• It allows negative indexing into arrays and strings.

I prefer to keep json range unit compatible with JSON pointer (and JSON patch). So let's have both for now and see where we go from there.

Also, BTW, if we are defining a new path format, why not just make it JSON and have it be instead of .foo.bar or /foo/bar be simply ["foo", "bar"]. Easy to read, easy to write, and all escaping rules are already defined.

[mitar]

Also, any range unit should also make sure it supports: #45

[toomim]

The issue now is that the json range unit is inconsistent across specs.

In braid-http it's specified as json .messages[2] and in range-patch it's json /messages/2.

We need to decide on one of them and then make the specs consistent.

[mitar]

I think the idea of this issue is to introduce a new range unit name (you renamed the issue, so it is slightly confusing now).

[toomim]

I'm sorry that the change in this issue's title wasn't clear.

The previous title started from the assumption that the /messages/2 format should get the json name, but we don't have consensus on that. (I, for one, still believe that messages[2] is a better format for json.) Thus, we are left with the general problem of two competing formats for a JSON range unit, and they are both in the spec, and both of them call themselves json.

In other words, we have two range units that want to be called json, and we have no consensus one which one should get that name.

Does that clear up the change in this issue's title for you? Are you ok with that?

[canadaduane]

Is there a PR or specific proposal on this?

The ".foo" syntax is preferred, IMO, because it is a more common way to specify JSON paths. For example, some common tools:

• https://stedolan.github.io/jq/tutorial/
• https://github.com/simeji/jid
• https://github.com/trentm/json
• https://github.com/ploubser/JSON-Grep
• and many more (see https://ilya-sher.org/2018/04/10/list-of-json-tools-for-command-line/)

In other words, I think RFC6901 JSON Pointer is now considered an "obscure syntax" for JSON path specifiers in 2021.

Also, BTW, if we are defining a new path format, why not just make it JSON and have it be instead of .foo.bar or /foo/bar be simply ["foo", "bar"]. Easy to read, easy to write, and all escaping rules are already defined.

I think it would be confusing to have a line that says json=["foo", "bar"] because it looks like the path specifier IS the json, rather than a path specifier referring to some OTHER json.

[toomim]

There's also an IETF Working Group for JSONPath, which formed just this year. It uses the javascript dot and brackets notation:

   $.store.book[0].title

The /store/book/0/title slashes notation was derived from XPath which was created for XML. JSON is a more modern alternative to XML, based on Javascript instead of XML things. I think a range unit for the name json should also reflect Javascript rather than XML syntaxes.