Relative JSON-pointer extension

[epoberezkin]

The proposal is to extend relative JSON pointer (https://tools.ietf.org/html/draft-luff-relative-json-pointer-00) to be able to refer to the items in array with some relative position.

Originally filed as: json-schema/json-schema#223

The syntax extension can be really simple, from the current N/JSONpointer to N+M/JSONPointer (to traverse N levels up and M items forward) or N-M/JSONPointer (M items backward), where N == 0 can possibly be dropped.

That would allow, for example, to implement restrictions on the array such as ascending/descending order (using $data v5 proposal).

Ascending order without duplicates:

{
  "type": "array",
  "items": {
    "type": "integer",
    "minimum": { "$data": "-1/" },
    "exclusiveMinimum": true
  }
}

Objects ordered in ascending order by unique id property:

{
  "type": "array",
  "items": {
    "properties": {
      "id": {
        "type": "integer",
        "minimum": { "$data": "1-1/id" },
        "exclusiveMinimum": true
      }
    }
  }
}

[handrews]

Should we first have an issue somewhere to revive the Relative JSON Pointer I-D? Is that part of this project or does it need to be revived separately?

[Anthropic]

@handrews I think if we can agree on what to modify then it would need a revival issue...

@epoberezkin can I suggest that we consider bracketing like N{-M}/ and N{+M}/ to allow for the same syntax at depth. I'm dealing with a UI at the moment so complex it has three arrays depth and many depths of object intertwined. So if I am working with the UI-Schema and not just the JSON-Schema then I would need to be able to define multiple array positions at depth not just in the first position.

The baz example where "0#" gets the current array position doesn't suffice when I need to define something more inline. If I have team[3].player[4].stats.game[4].plays and I want to get to team[3].player[5].stats.game[4].plays from plays, I would need "4{#+1}/stats/game/{#}/plays" to indicate back to the next player for the same details if we keep hash as meaning the current index.

[handrews]

For reviving the RFC I-D at all, see #126 (we need it for various things whether we want to change it or not).
[EDIT: It has since been revived and two further drafts published with a third underway.]

[handrews]

I have a few concerns about this proposal.

• Only allowing relative array indices on the first token of the JSON pointer is limiting and confusing.
• Allowing relative array indices anywhere requires some sort of escaping as any string can be a JSON property name.

[EDIT: The following definitely no longer true, and the point was dubious and contested in the first place]

• Adding more escaping will make Relative JSON Pointer incompatible with JSON Pointer (currently, since relative JSON pointers are proposed as an extension, all regular JSON pointers are also legal relative JSON pointers with the same meaning).

[epoberezkin]

@Anthropic I think relying on the sequential number being the same in different arrays is an uncommon (and also fragile) use case, usually IDs are used to cross-reference the objects.

Only allowing relative array indices on the first token of the JSON pointer is limiting and confusing.

@handrews that's the most commonly needed use case that allows to implement several common constraints (such as ascending/descending, other sequences)

all regular JSON pointers are also legal relative JSON pointers with the same meaning

@handrews that is incorrect - regular pointers must start with / while relative start with a number, regular are from root, relative are from the current point.

While we can consider an even more radical extension to something like JSON-pointer expression (that would need to cover some arithmetics maybe?) a simple extension allowing to navigate to sibling items from the current item would have been very useful (even if not covering everything).

So essentially, I believe that "up" -> "left/right" -> "JSON pointer" is much more powerful than "up" -> "JSON pointer" and still doesn't require any additional escaping characters or other dramatic changes.

[epoberezkin]

It really only makes sense to move laterally when the array is at the "top" of your path, right?

For the common data designs, yes. As I wrote it is uncommon (and fragile) design when items in different trees are correlated by the index rather than by some id.

[handrews]

@epoberezkin as I have resolved the grammatical argument [EDIT: meaning the argument over my interpretation of "extension"] in your favor with #446 (assuming you agree), once that is merged I plan to delete the comments involved in that argument so that future readers can focus on the actual point of this issue. There are plenty of examples of the handrews/epoberezkin argument show elsewhere ;-P

[EDIT: GitHub makes it look like I just deleted epoberezkin's comments, for some reason it does not show that I deleted my own comments as well]