Minutes IETF112: jsonpath
minutes-112-jsonpath-00

# JSONPath IETF 112 Working Group Minutes
Date: 2021-11-10
Time: 12:00 - 14:00 UTC

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

# Agenda Bashing
* Glyn: Cover Regex (#70)

# Discussion

## Regular Expressions - #70
Tim: We had consensus last meeting that we can't have regex in JSONPath without
defining the regular expressions As things stand now, we won't have regex in
filtering

Carsten: I have a slide on that

Tim: Let's push that on the stack

## Draft Status - Tim

Tim: The draft has the important parts, with editorial notes to be added
Carsten what needs further discussion?

Carsten: I tried to tackle the big things in preparation, some of these should
go into issues We need another editorial round, but most of it is done

Tim: In Section 3.5, I was hoping for examples, is there agreement?

Carsten: There are several ways to do examples, such as an appendix with at
least one example

Tim: When I read a spec, I find it so much happier with prose and an example of
what it looks like

Glyn: I agree, but the dangers are people don't define things in a normative way

Tim: I'll just leave it as a suggestion and might go to make a PR

**Action** Tim to make a PR

Tim: How much work do we have left here? Would we be able to bring a draft to
the IESG next IETF?

Glyn: That's probably doable, but I'm not working on compliance or test suite

## Containable Structured Types - #127

Tim: I agree with what you said with array only and literal only

Glyn: I was concerned about the element of suprise with left side elements

Tim: Looking at the examples, it's about the left hand side?

Carsten: The issue is about the right hand, but without structured values we
can't write the second array example

Glyn: The last comment agrees with my critque of subsets

Carsten: This is just a question about user requirements, would be great if
users would tell us if they need it

Tim: This does add noticable complexity, my instinct says leave it with
literals only

Glyn: Do we need the 'in' operator at all?

Darrel: I can think of a scenario where we 'in' a structure, allowing 'in' with
primitive is a nice compromise

Tim: Literals in arrays would not be hard to specify

Carsten: We should define the semantics of 'in' so we don't repeat ourselves

Glyn: My concern with 'in' is having a path on both sides, which would violate
the principle of least surprise

Carsten: What does it mean to have a path in a comparison?

Tim: We could solve it with literals on the left side?

Carsten: That would be weird, more interesting is what happens if it's on the
right side?

Tim: Darrel, what would your queries look like?

Darrel: We want to know if a literal is in a list of traits

Stefan: This is a good example of #122 where we are generating of object
members and query by the in operator

Carsten: We don't have to turn it into an array, but it's a useful analogy

Glyn: Instead of allowing a general path, permit a limited path of nodelist of
a single value

Darrel: I presume you can put an 'in' in a filter expression?

Carsten: You mean a nested query filter?

Carsten: We need to make examples that show we don't need the filter on the
left hand side, which will simplify things

Tim: Then it would seem much less valuable

Stefan: I agree with Carsten's approach

Tim: Do we have use cases for an array literal on the right

Darrel: It becomes a shorthand for 'or' at that point

Tim: Editors should we include it

Carsten: I don't think it's a problem

Glyn: I'd like to see a use case that can't be satisfied by filters alone,
maybe Darrel has one

Please see examples in:
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-redacted

James Gould: The goal of the draft is that RDAP is JSON version of WHOIS, and
the draft explicitly specify which JSON members are redacted information for
privacy reasons

Tim: These examples look like filters not the 'in' operator

Glyn: I think we just ran out of use cases

Darrel: I think our traits scenario needs 'in'

Carsten: You'd use a nested filter expression

Tim: Sounds like 'in' is syntactic sugar

Tim: Are you okay with just leaving it out?

Stefan: 'in' can be substituted for a chain of 'or' expressions

**Consensus**: 'in' won't be used, but it will be easy to add later if there's
real demand

## Processing Extension - #124

Carsten: I would like to not do this

James Gruessing: This should be part of the extension space

Stefan: It adds a lot of complexity

Carsten: The main problem with the proposal is that it destroys data
transparency

**Consensus**: Won't be included in the specification, but can be part of
extensions

**Action**: Carsten to comment that consensus is to leave it for an extension

## Absent equal to absent - #123

use case contest

Tim: I see Javascript behaviour is `undefined == undefined`

Darrel: I don't think I'm intentionally trying to detect that issue

Stefan: We don't have an undefined datatype in JSON, we can only convert it to
`false`

Tim: To me this feels like NaN

Tim: What you want is an exists predicate?

Carsten: We have that already

Tim: cburgmer posted on the issue saying there's no consensus, not even a
majority

Darrel: We're using this for filters, in the case of "does not exist" we don't
know about equality, and I thought the behaviour is "don't return if you can't
compare", which goes back to the NaN debate

Carsten: We should look at the use cases to decide `undefined` vs `NaN`

Tim: So you'd like `undefined` behaviour?

Carsten: Yes, but it seems that others like `NaN` better

Carsten: Whatever we decide, we can always write an existence test that
inverts, my feeling `undefined` is the right feeling

Tim: Should we have a use case contest on this?

**Action**: Discuss the use cases of this on the mailing list

## Truthiness - #119

Tim: You're in favour of pure existence test?

Carsten: Yes

Glyn: I fully support that

**Consensus**: In boolean contexts, path converts to false if nodelist empty,
but does not check value(s)

**Action**: Carsten to make further edits based on consensus

## Normalization - #117

Tim: If you want normalization, you have to ask for it

Carsten: Totally agree with that

Tim: I prefer codepoint comparison over byte comparison

**Consensus**: Normalization not part of spec, codepoint comparison should be
used

## Filtering without child selection - #109

Carsten: Maybe the problem is that we don't have a way to get at the key of a
member

Stefan: All we can do is iterate over the argument, and get the values but not
address the key

Stefan: We need something like a function to get the key of a member

Stefan: This is not possible at the top level

Carsten: This is a problem with what to return, not with selecting, and you
can't undo the "diving" into the structure

Glyn: There's a lack of clarity in the issue

Stefan: We need an example chapter in the spec for examples and solutions like
this

Glyn: I think this breaks our processing model and we shouldn't support this

Darrel: JMESPath is focused on projections, and JSONPath should focus on
selection

Tim: I think we acknowledge the issue, I don't see interest in trying to solve
it

Stefan: Doesn't happen very often

**Consensus**: We acknowledge but won't address this issue

**Action**: Carsten to update the issue

## Syntax for number of filtered elements (aka pagination) - #95

Darrel: I'm not sold on paging, but limits are a valuable use case

Tim: Could you do that with slice?

Glyn: Slice for arrays, this is about nodelist

Stefan: We should decide on postprocessing of results vs. extend query

Darrel: There's no ordering available, it's just a limit capability

Tim: This feels like an API problem, not an expression

**Consensus**: This won't be part of spec as it's an API problem but could be
included in future

## Regular Expressions - #70

Tim: Is there a regex flavour we can select?

Carsten: There's two

Glyn: Regex syntax seems to be an orthoganol concern

Tim: I don't think JSONPath implementers should have to implement regex as well

Darrel: Most people I know working with JSONPath are working with JSONSchema,
who've picked ECMA 262, with recommendation for a subset

Stefan: iregexp might be the way to go

**Action**: Take this discussion to the list