**Session Date/Time:** 10 Jan 2023 08:00

# [JSONPATH](../wg/jsonpath.html)

## Summary

This meeting focused primarily on reviewing open issues for the JSONPath draft. Key discussions included the adoption of new Unicode escape syntax, whitespace flexibility, the nature of functions (pure functions and short-circuiting), handling of `optional Boolean` return types in existence tests, scoping within nested filters, and simplification of the type system by removing the 'Absent' type. Several editorial and technical decisions were made, leading to action items for draft updates and preparation for an upcoming I-RegEx PR.

## Key Discussion Points

*   **I-RegEx Update**: The chairs provided an update on the I-RegEx draft. The JSON Schema use of anchors differs from JSON Path. I-RegEx aims to provide an interoperable set of regular expression functionalities. Further clarification is needed on how to derive ECMAScript and PCRE versions from I-RegEx. This clarification will be submitted as a working group last call comment.
*   **Issue 272: Unicode Escapes (`\u{CODEPOINT}` Syntax)**: The discussion revolved around adopting the ECMAScript `\u{CODEPOINT}` syntax for Unicode escapes in addition to the standard JSON `\uXXXX` syntax.
    *   **Arguments for**: Easier to write non-BMP characters. Many languages now support this brace syntax.
    *   **Arguments against**: Extension over standard JSON, potential surprise for implementers.
    *   A sense of those present indicated a preference for adopting this for usability.
*   **Issue 273: Liberal Whitespace**: The current grammar allows liberal use of whitespace. The question was whether to restrict this to reduce potential interoperability issues.
    *   **Conclusion**: Restricting whitespace would hinder readability for complex queries, especially multi-line expressions. Usability outweighs the interoperability concern for optional whitespace.
*   **Issue 310: Non-Optional Functions**: This issue concerned the mandatory nature of functions defined in the JSONPath specification.
    *   **Conclusion**: The issue was deemed overtaken by events, as `dash09` already reflects the desired state of mandatory functions.
*   **Deduplication of Node List (Section 2.6.5)**: An editor's note in section 2.6.5 regarding the absence of node list deduplication was discussed.
    *   **Conclusion**: The editor's note should be removed, explicitly stating that no deduplication occurs.
*   **Issue 335: Short-Circuiting and Pure Functions**: The discussion centered on whether the specification should address short-circuiting of logical operations and if functions in JSONPath should be considered pure (without side effects).
    *   **Concern**: If future function extensions have side effects, short-circuiting could change observable behavior.
    *   **Proposal**: Add text explicitly requiring functions to be pure (no observable side effects beyond their return value) and clarifying that implementations *may* short-circuit evaluation. This avoids specifying evaluation order while allowing optimization.
*   **Issues 345 & 335 (Boolean Predicates & Existence Tests)**: These issues intertwined around the handling of Boolean values in predicates and the special casing of `optional Boolean` return types from functions like `match` and `search` in existence tests.
    *   **Issue 345 (part 1)**: Allowing direct use of Boolean values (e.g., `== true`) in comparisons. A sense of those present indicated not to add this functionality now, as it doesn't add core functionality and can be added later if needed.
    *   **Issue 345 (part 2)**: Clarifying the behavior of `optional Boolean` function return types in existence tests. A `false` value from an `optional Boolean` function should *not* pass an existence test. This requires specific text to address this special case and prevent "referential transparency" confusion.
*   **Issue 347: Nested Filter Expressions and `@` Scoping**: The grammar implicitly allows nested filter expressions. A scoping problem exists where `@` (current node) refers only to the innermost scope, not parent levels.
    *   **Conclusion**: Supporting nested filters is important. The `@` scoping limitation is acknowledged but deferred for future consideration pending user feedback. The specification should explicitly state that nested filters are allowed and clarify the `@` scoping.
*   **Issue 348: 'Absent' Type in Function Signatures**: The utility of the 'Absent' type in the type system, particularly as a function return type, was questioned.
    *   **Discussion**: While it helps keep the type hierarchy clean, it is not a useful concrete return type. `Nothing` is an instance, and 'Absent' is a concrete type representing the absence of a value.
    *   A sense of those present indicated a preference for a leaner type system.
*   **ABNF Grammar Review**: General discussion about simplifying and clarifying the ABNF grammar. This includes renaming certain productions for better clarity and consolidating synonyms.
    *   **Conclusion**: There's "fat" in the ABNF that could be compressed or clarified.

## Decisions and Action Items

*   **Decision (Issue 272)**: Adopt the ECMAScript `\u{CODEPOINT}` syntax for Unicode escapes.
    *   **Action**: A volunteer to submit a Pull Request (PR) for this change.
*   **Decision (Issue 273)**: Do not restrict optional whitespace in the JSONPath grammar.
    *   **Action**: Issue 273 is closed.
*   **Decision (Issue 310)**: Close issue 310, documenting that functions in the spec are non-optional/mandatory ("batteries included" for regex).
    *   **Action**: Issue 310 is closed.
*   **Decision (Deduplication)**: Remove the editor's note in Section 2.6.5, explicitly stating that no deduplication of the node list occurs.
    *   **Action**: A PR to remove the editor's note.
*   **Decision (Issue 335 - URI Encoding)**: Use "percent encoding" instead of "URI encoding."
    *   **Action**: Editorial change to correct terminology.
*   **Decision (Issue 335 - Short-Circuiting)**: Add text to the draft to clarify that functions should be pure (no observable side effects beyond their return value) and that implementations *may* short-circuit evaluation of logical expressions.
    *   **Action**: A PR to add this clarifying text. Issue 335 is closed based on this resolution.
*   **Decision (Issue 345 - Boolean Predicates)**: Do not introduce direct comparison of Boolean values (e.g., `== true`) at this time.
*   **Decision (Issue 345 - Optional Boolean in Existence Tests)**: Add clarification text in the existence test section to explicitly define how `optional Boolean` return values from functions are interpreted (i.e., a `false` value does not pass an existence test).
    *   **Action**: A PR to add this clarifying text.
*   **Decision (Issue 347)**: Explicitly mention that nested filter expressions are allowed, and clarify that the `@` symbol refers only to the innermost scope. Defer addressing the `@` scoping limitation for parent/upper levels for future versions or based on user feedback.
    *   **Action**: Editorial changes to clarify text regarding nested filters and `@` scope.
*   **Decision (Issue 348)**: Remove the 'Absent' type from the type system in the draft.
    *   **Action**: A PR to remove the 'Absent' type.
*   **Action (I-RegEx PR)**: Tim will submit a PR with clarification on deriving ECMAScript/PCRE from I-RegEx, to be a working group last call comment.

## Next Steps

*   Chairs to continue processing PRs for the decisions made.
*   Refactor the ABNF grammar in small, manageable steps (individual PRs) to improve clarity and reduce redundancy.
*   Schedule the next interim meeting approximately four weeks from now (around February 7th, Week 6).
    *   **Action**: James will send out a Doodle poll for the next interim meeting.