# 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