Agenda jsonpath IETF 109 Working Group Agenda Date: 2020-11-16 Time: 16:00 ICT

Chair: Tim Bray Chair: James Gruessing Area Director: Murray Kucherawy

  1. Administrivia
  2. Note Takers
  3. Jabber Scribe
  4. Agenda Bashing

  5. added compliance test suite to agenda.

  6. Discussion of Documents

  7. Compliance Test Suite

Tim suggests that the consensus is that we are receptive/friendly to having test cases.

  1. Should we specify a scripting language?

Cabo: what does this mean? the original language says to use whatever you have. That's not very useful. Specifying the language might mean we come up with an expression language here. Or it might mean we say, "let's all do Python". Cabo says that expression language is yes, and "language FOO" is no. Rick: agrees strongly. Julian Reschke: never say "regex" and "limited complexity" in one sentence Glyn: there is a distinction between filters vs scripting (open ended). The filters were very clean. On the other side, there was a lack of consensus.

Tim: The sense of the group is that the filtering capability is well supported. Nobody wants to either adopt an existing language, or invent a new one.

  1. What can we say about the result of evaluating a JSONPath?

Initially people said that everything that results is an array, and this was surprising to some people. Rick: there is a mutability issue, which has worried me about JSONpointer, and which might appear. If one returns an array of results, then that result is a new array, and is a copy. (i.e. GC scripting language). But a filter that returns you a single item, then it can return a pointer directly to the item. And avoiding allocations is important. Julian: there are different ways of using JSONpath, which could have wildly different issues. Glyn: sympathy for memory issue. Distinguish between single item vs array[1]. cabo: the abstract model is JSON-tree as input, and it has positions in it. Then the JSONpath results in a set of positions as output. (Maybe each position has a boolean) The problem then becomes how do we represent this in environment X? The original document talks about returning the values at those positions. But, we should think of returning a mark of the tree as being part of the result , or not part of the result. Tim: worried that we won't be able to specify this well... AWS applies this to millions of events - JSONPath used to select pieces of those events to route to destinations, so if you say "$.a.b" it's reasonable for the output to be "23". If the spec ruled out some use cases, it would a problem.
Rick: this is a discussion of return-by-value vs return-by-reference. JSONpointer is a way to do return-by-reference (into the original tree). Happy that we are having this discussion. Cabo: <missed that> Glyn: likes the abstract model, and the colouring of the tree.
Marko: discusses how the arity of the result will be discussed. Rick: find-first vs find-all? Tim: should we specify an API? Rick: maybe not quite so far... binding for language. But something a bit in that direction.... Here are some concerns... cabo: find-first vs find-any? no guarantee that it is the first. cabo: So we can have one abstract model of what JSONpath does and derive multiple (abstract) APIs from that

Tim: we agreed that the variety of uses of how a JSONpath expression can be used makes it difficult, but we can write strong guidance.

Rick: It may be worth enumerating the ways of acquiring a result, and these should be normatively named. Glyn: What is our attitude to non-determinism in the specification? Marko: I have strong feelings against using JSONPath as a way of pointing at things, particularly JSONPointer cannot navigate through structures with arrays apart from using the array index

  1. AOB

cabo: timelines?

James: Mid-2021 draft submission to IESG, but aim for the personal drafts to be merged an a WG-adopted -00 draft published by the next IETF meeting Murray: The milestone can be renegotiated

Tim: WG draft by March with non-controversial cases Glyn: I'm trying to work on the non-controversial issues, and I'm curious on how accommodating we should be about existing implementations Tim: We should realise what we're building is probably for future implementations and the existing implementations will likely not change. cabo: There is a cost to deviating from existing practice, there is also a cost to putting in something expensive. The consensus seems to be in the direction of existing practice, but I would be unhappy if we never could clean anything up. Murray: The charter actually brings this up, you might want to review this and tweak it if required