* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Jsonpath Status Pages

JSON Path (Active WG)
Art Area: Francesca Palombini, Murray Kucherawy | 2020-Oct-23 —  

IETF-112 jsonpath minutes


minutes-112-jsonpath-00 minutes

          # 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
          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:
          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
          **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
          ## 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
          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

Generated from PyHt script /wg/jsonpath/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -