**Session Date/Time:** 14 Jun 2022 08:00

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

## Summary

This JSONPATH interim meeting focused on preparing both the JSONPath base document and the IREGEX document for Working Group Last Call (WGLC). Key discussions revolved around resolving outstanding GitHub issues, particularly concerning IREGEX's handling of Unicode, the security considerations and string normalization for JSONPath base, and a significant debate on the inclusion of an extension mechanism for JSONPath. A shepherd was identified for IREGEX, and an action was taken to draft a concrete proposal for JSONPath extensions. The working group expressed confidence in submitting both drafts for publication this year.

## Key Discussion Points

*   **IREGEX Document Status**
    *   **James Clark's Feedback:** Feedback from James Clark regarding regular expressions was discussed.
        *   **Script References:** It was noted that allowing script references in `\p` constructs would be a major change, going beyond W3C regex, and therefore will not be adopted.
        *   **Block References:** Concerns about block references (e.g., `\p{IsBasicLatin}`) were reviewed. James Clark's perspective convinced the group that block references should be removed to simplify the specification and align with existing regex standards.
    *   **Pull Request:** Carsten submitted a Pull Request (PR) to remove block references.
    *   **Decision:** The working group agreed to remove block references from IREGEX.
    *   **Working Group Last Call (WGLC):** The IREGEX document is considered ready for WGLC.
    *   **Document Shepherding:** Tim, as an author, cannot shepherd the document. James Clark volunteered to shepherd the IREGEX document.
    *   **WGLC Sequencing:** It was agreed that the IREGEX WGLC should be conducted separately and precede the JSONPath base WGLC due to dependencies.
    *   **Action:** James Clark will create a draft shepherd write-up for IREGEX. Tim to review Carsten's PR for removing block references.

*   **Security Considerations (Issues 185, 186)**
    *   Discussion focused on editorial improvements, particularly around clarifying determinism, ordering, and handling of duplicate keys in JSONPath processing.
    *   **Issue 185:** Deemed adequately discussed and resolved.
    *   **Decision:** Issue 185 was closed.
    *   **Issue 186:** Further editorial work was identified.
    *   **Action:** Glenn will undertake editorial work to incorporate suggested language regarding determinism, ordering, and duplicate keys into the security considerations section.

*   **String Normalization (Issue 117)**
    *   The issue of string normalization was revisited. It was confirmed that existing normative text in the draft sufficiently addresses concerns.
    *   **Decision:** Issue 117 was confirmed as closed.
    *   **Action:** Tim will ensure the issue is formally closed with the correct commit hash.

*   **Extension Mechanism (Issues 154, 160, and new issue)**
    *   An extensive discussion took place on the need for a formal extension mechanism for JSONPath to prevent ad-hoc implementations and potential fragmentation of the standard.
    *   **Rationale:** The group acknowledged that demand for additional functionality (e.g., `length` function, `about` function) indicates that implementations will extend JSONPath regardless, making a controlled mechanism desirable.
    *   **Proposed Mechanism:** Discussion gravitated towards an IANA registry for managing extensions, defining names and semantics, and functional syntax as a promising approach for the extension point itself.
    *   **Concerns:** Tim expressed reluctance towards optional features in standards, citing the interoperability challenges seen in SQL. The counter-argument highlighted that a well-managed IANA registry and a defined registration policy would mitigate such risks, unlike SQL.
    *   **Behavior on Unsupported Extensions:** It was noted that the specification would need to define the behavior when an implementation encounters an unsupported extension (e.g., fail hard).
    *   **Decision:** Carsten will develop a concrete proposal for a JSONPath extension mechanism, likely starting with functional syntax and incorporating the concept of an IANA registry. This proposal will be informed by existing requests for features like a `length` function (Issue 154) and an `about` function (Issue 160).
    *   **Action:** Carsten will draft a proposal for the extension mechanism. An "extension" label will be added to relevant GitHub issues to track them.

*   **Draft Status and Remaining Issues for JSONPATH Base**
    *   There was a sense of the room that the JSONPath base document is nearing WGLC readiness, with many GitHub issues already resolved or being editorial in nature.
    *   **Issue 159 (Editorial Query):** Closed as addressed, with no further reaction from the opener.
    *   **Issue 188 (Operator Precedence/Associativity):** Daniel requested more comprehensive documentation on operator precedence and associativity.
        *   **Action:** Tim will post a comment requesting a concrete proposal for any needed changes beyond adding an associativity column to the precedence table. Glenn will take on improving the documentation of associativity.
    *   **Issue 180 (Confusing `exists` semantics):** The current definition was deemed sufficient.
        *   **Decision:** Issue 180 was closed.
    *   **Issue 172 (Value Type Checks):** Identified as a future direction rather than a current change.
        *   **Decision:** Issue 172 was closed.
    *   **Issue 162 (Make `@` sign optional):** Discussed as an editorial matter. The group felt that providing rationale for the `@` semantics might be beneficial.
        *   **Action:** Editors will consider adding rationale to the document. The issue remains open for editors to close once addressed.
    *   **SQL JSONPATH Comparison:** A discussion about mentioning SQL/JSONPath in the draft concluded that it wasn't necessary or beneficial, as the influence was not from SQL/JSONPath to JSONPath.
        *   **Decision:** The group reached a sense of consensus not to include a comparison with SQL/JSONPath. The issue was closed.
    *   **Issue 157 (Declarations of Objects):** After discussion, it was concluded that this was not a relevant role for JSONPath.
        *   **Decision:** Issue 157 was closed.
    *   **Addressing Object Keys:** It was acknowledged that resolving this issue would require significant changes to the processing model, which is not feasible for JSONPath base 1.0.
        *   **Decision:** No action on this for 1.0; revisited for future versions.
    *   **Issue 123 (`null` and `absent` Semantics):** The current text in Section 3.6 (Semantics of Null) was deemed sufficient to clarify the handling of `null`.
        *   **Decision:** Issue 123 was closed.
    *   **Issue 55 (Requirements from RARE Things):** Labeled as "revisit after base done" and acknowledged for future consideration, possibly in conjunction with an extension mechanism.
    *   **Duplicate Selector Output:** The group reached agreement on this.
        *   **Action:** An editorial check will be performed to ensure the document accurately reflects this agreement.

*   **Milestones and Timelines**
    *   The working group's goal of IESG submission for JSONPath base this year was reaffirmed.
    *   Proposed milestones for both JSONPath base and IREGEX: Submit for publication before IETF 115 (November). There was a sense that this is a realistic and achievable target.
    *   **Action:** Chairs will add this milestone for IREGEX and JSONPath base for AD agreement.

*   **Participant Engagement**
    *   An unnamed participant inquired about submitting their draft related to SDN and ALTO, and incorporating JSONPath.
    *   **Advice:** It was strongly recommended that the participant post their draft to the JSONPATH mailing list for broader review and discussion. For the ALTO-specific aspects, engaging with the ALTO working group was suggested. The general method for IETF work (mailing lists, GitHub issues/PRs) was explained.

## Decisions and Action Items

*   **IREGEX:**
    *   **Decision:** Remove block references from the IREGEX specification.
    *   **Action (Carsten):** Ensure PR for removing block references is ready for review and merge.
    *   **Action (Tim):** Review Carsten's PR for removing block references.
    *   **Decision:** IREGEX is ready for Working Group Last Call (WGLC).
    *   **Decision:** IREGEX WGLC will precede JSONPath base WGLC.
    *   **Decision:** James Clark will serve as the shepherd for the IREGEX document.
    *   **Action (James Clark):** Prepare a draft shepherd write-up for the IREGEX document.
*   **JSONPath Base - Security Considerations:**
    *   **Decision:** Issue 185 (Security Considerations) is closed.
    *   **Action (Glenn):** Perform editorial work on Security Considerations (Issue 186) to incorporate language regarding determinism, ordering, and duplicate keys.
*   **JSONPath Base - String Normalization:**
    *   **Decision:** Issue 117 (String Normalization) is closed.
    *   **Action (Tim):** Formally close Issue 117 with the correct commit hash.
*   **JSONPath Base - Extension Mechanism:**
    *   **Action (Carsten):** Develop a concrete proposal for a JSONPath extension mechanism, including syntax (e.g., functional syntax) and the role of an IANA registry.
    *   **Action (Chairs):** Add an "extension" label to relevant GitHub issues (e.g., 154, 160) to track items dependent on the extension proposal.
*   **JSONPath Base - Remaining Issues:**
    *   **Decision:** Issue 159 (Editorial Query) is closed.
    *   **Action (Tim):** Add a comment to Issue 188 (Operator Precedence/Associativity) requesting a concrete proposal for any needed changes.
    *   **Action (Glenn):** Improve the documentation of operator associativity (Issue 188).
    *   **Decision:** Issue 180 (Confusing `exists` semantics) is closed.
    *   **Decision:** Issue 172 (Value Type Checks) is closed.
    *   **Action (Editors):** Consider adding rationale for the choice of `@` sign semantics (Issue 162). Issue to be closed by editors once addressed.
    *   **Decision:** Consensus reached not to include a comparison with SQL/JSONPath in the document. Issue is closed.
    *   **Decision:** Issue 157 (Declarations of Objects) is closed.
    *   **Decision:** Issue 123 (`null` and `absent` Semantics) is closed.
    *   **Action (Editors):** Perform an editorial check for agreement on duplicate selector output.
*   **Milestones:**
    *   **Action (Chairs):** Add a milestone for "Submit IREGEX and JSONPath Base for publication before IETF 115" for AD agreement.

## Next Steps

*   Chairs to update GitHub issues with labels and closures as per decisions.
*   Carsten to begin drafting the extension mechanism proposal.
*   James Clark to start on the IREGEX shepherd write-up.
*   Glenn to address editorial changes in Security Considerations and operator associativity.
*   Tim to review Carsten's PR for IREGEX.
*   Chairs to schedule the next interim meeting (doodle poll for week of August 15th).
*   All participants are encouraged to review the updated drafts and engage on the mailing list and GitHub.