Minutes interim-2021-jsonpath-03: Fri 09:00

Meeting Minutes JSON Path (jsonpath) WG
Title Minutes interim-2021-jsonpath-03: Fri 09:00
State Active
Other versions markdown
Last updated 2021-09-21

Meeting Minutes

jsonpath IETF Working Group September 2021 Interim

Date: 2021-09-17 Time: 9:00 - 11:00 UTC

Chair: Tim Bray Chair: James Gruessing Area Director: Francesca Palombini

VC Details




  • Note Takers
  • Blue Sheets
  • Jabber Scribe
  • Agenda Bashing

Discussion of Issues

Carsten's slides

Glyn: Nodelist passed as individual nodes to the selector

Stefan: Beyond slide 5: * in-operator * existence test

Stefan: Good to restrict the RHS of comparisons to simple [primitive] values

Tim: runtime...

(We think Greg has been pushing for structured values in comparison)

Meeting consensus seems to be to stick with primitive values for comparisons

cabo: path-to-path comparison

Stefan: first reaction: disallow this

Glyn: Proposal A avoid multiple nodes by limiting the path on the $ side as well, only where they will yield a definite value

Tim: syntactic restriction? Glyn: single value may be an array, but is not multiple nodes...

Glyn: single value may be structured

Meeting consensus appears to be to limit comp-expr to the equivalent of https://github.com/cburgmer/json-path-comparison/blob/master/proposals/Proposal_A/selector.peg

Stefan: (1) But then there is the in-op (2) allow existence test -- structured value does exist... cabo: not spelled out -- only confusingly as "falsy" and "truthy"

See issues #120 and #122


11 of 4x implementations do that "right" Function proposal ("exist()")?

Carsten: stick with exist-expr... use that for existence testing Use comp-expr to find out whether an existing value is 17, "a", false, null, or true. (A non-existing value is not equal to any literal. @.doesnotexist != 17 is true, as is @.doesnotexist != false.) Discuss: @.doesnotexist != @.alsodoesnotexist, note that undefined is not equal to undefined in language X (True of NaN in most languages, not of undefined in JavaScript .)

For $.foo == $.bar, user might expext that to be true if both members are missing.

$.foo && $.foo == $.bar could be used for the inverse case.

$.foo == $.bar || !$.foo && !$.bar would be needed otherwise.

<pre>> NaN == NaN false > NaN != NaN true > NaN < NaN false > NaN <= NaN false > NaN > NaN false > NaN >= NaN false </pre>

$.foo in \[] is always false, as is xin \[] for any x

-> add examples to (filter selector)


Tim: leave RE out, as trying to make this consistent will make people unhappy.

James: RE could be for extensions in the future.

Carsten: (iregexp) https://www.ietf.org/archive/id/draft-bormann-jsonpath-iregexp-00.html Implementation: transform this common subset into the RE language at hand (surprisingly easy)

Glyn: One standard spawning another activity; actually quite general not limited to jsonpath

Tim: Once we allow regexp, we have to say what we mean.

Stefan: like to export the RE syntax to another specification

Stefan: What would be an extension point?

Carsten: Provide a well-defined place where extensions can be plugged in

Glyn: E.g., there could be a JSONPath over RE2?

Carsten: Separate issue: Policy for granting extensions

Tim: SGML declaration, had dozens of optional features, nightmare

Tim: Statement I'd like to be able to make: Any (conforming) JSONPath can be processed by any (conforming) JSONPath implementation

Emerging Consensus: If we allow regular expressions, we need to say exactly what they mean.

Options: (A) No RE. (B) Full spec of RE included.

James: There may be need for Extension Points for other things than RE.

James: Implementers may want to offer a different RE definition...

(Can't define common subset, but also need transformation...)

Tim: UTF-8 characters in RE should always work, classes more interesting

Consensus on options A or B above.

Actions? (X) Develop ideas about what could be viable extension point mechanisms (Y) Examine iregexp


List of issues to discuss to be finalised later


Do schedule a 112 meeting

Interim? Not enough time.