# JSONPath IETF 112 Working Group Minutes
Time: 12:00 - 14:00 UTC
* Chair: Tim Bray
* Chair: James Gruessing
* Area Director: Francesca Palombini
# Agenda Bashing
* Glyn: Cover Regex (#70)
## 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
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
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
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:
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
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
## 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
**Consensus**: Won't be included in the specification, but can be part of
**Action**: Carsten to comment that consensus is to leave it for an extension
## Absent equal to absent - #123
use case contest
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
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
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?
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
## Filtering without child selection - #109
Carsten: Maybe the problem is that we don't have a way to get at the key of a
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
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
Tim: I think we acknowledge the issue, I don't see interest in trying to solve
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