# JSONpath WG 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 - added compliance test suite to agenda. 5. Discussion of Documents * use of RFC8874/8875 suggested as a mechanism. * silence/consent to using hybrid/github approach * going to have name co-editors: going to ask one of you to step forward, and if you aren't an editor, then you can argue on the list more! * have two WG documents, how should we move to a consensus WG document? * cabo: one from 2007, and another charging ahead. * 2007->introduction, and new one->details. * discussion about the different people available. * _nobody attached to notion that either document should start_? no objection! * a number of things which are now dangling links. * Glyn prefers to start with a blank slate, and copy and paste from other documents. 6. Compliance Test Suite * Tim would like to produce a compliance test suite which is congruent with document. * cabo: worries about ambiguities between test suite/document. * discussion about official/unofficial status of test suite. * maybe changes which are hard to test, are a problem. * Rick Taylor: a set of worked examples and canonical results would be good though * ACTION: Tim will take an action item to find out what the current practice is. * cabo: "we like to have good examples" / * Julian: "that's what we did for the HTTP structured headers spec" * was a language to describe header field syntax, and the MNOT came up with a set of inputs and expected outputs. * in the v3 work, we can tag source code with different values, and based upon the value found, run different validation tools on it. For instance, MNOT wrote HTTP validator. * Alexander: * if the suit is not complete, then some people might assume that if they pass the suite, then they are fully compliant. * Rick: the jsonpointer has some examples that might be useful to start with. * Tim has been involved with various DSLs, and the ones that have a command-line validator when they launch seem to succeed better. * Julian: another thought about test cases. Also good to have test cases for invalid syntax, with some suggested error text. Do we want to be have ??? tests? Tim suggests that the consensus is that we are receptive/friendly to having test cases. 7. 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. 8. 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: 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 13. 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