Minutes interim-2022-jsonpath-04: Tue 10:00
minutes-interim-2022-jsonpath-04-202206141000-00

JSONPath June Interim Minutes

Carsten: We have a PR for iregexp from James Clark, that we should be
allowing
script references in /p constructs and found W3C regex don't allow that.
He also
mentioned block references are relatively problematic, James convinced
me we
shouldn't. Does anyone have an opinion on unicode blocks?

Tim: I am fully supportive of this

Carsten: Can you please review my pull request?

Carsten: Are we going to do a WGLC separately?

James: I would argue they be done separately

Carsten: Will you be the shepherd for the document?

James: Yes, I can volunteer to do it

Carsten: What has been helpful in other WGs is the shepherd doing the
write up
before WGLC. But we don't have to do it that way.

Action: Tim to review the outstanding iregexp PR

Action: James to do the document shepherd writeup

Security Considerations (#185, #186)

Tim: We still have open issues on this, and PR's correct?

James: #186 is the second pass with your feedback

Tim: Glyn: You edited this most recently?

Glyn: I don't remember

Tim: Let's take 5 minutes to read it and see if we're happy

Carsten: I wouldn't mind adding Tim's text, I think being very explicit
is
always a good thing.

Action: Glyn to do some editorial work to include Tim's proposed
text

Tim: Any other issues on this?

James: Just these I believe

Glyn: Are you ready to close #185?

Tim: Closed

String Normalisation (#117)

James: Last we concluded was that we wouldn't do it

Tim: I made a PR, and Glyn you merged it

Glyn: We can just add a comment and close it

Carsten: We should have re-read

Extensions

James: There was an action in the last meeting to put a starting point
with
Carsten

Carsten: I don't remember that

Tim: I'm not convinced on this

James: We've talked about this before, what matters is the mechanism not
the
functionalities individually. There's a few existing proposals that
would
benefit; we need to define how to extend syntactically, and if not a
clear
statement saying it's unsupported.

Carsten: #154 is an example, as a general rule if we provide an
extension point
it's important to exercise it immediately. I'm not sure if we have done
a survey
of existing implementations, but more importantly we come up with a
solution for
the next decade or so.

Tim: How would we register extensions?

Carsten: You would just see if the extension is used, no need for
versions.

James: No obligation to implement the extensions.

Glyn: Two different parties could implement the same extension with
different
semantics?

Carsten: That's for the registry to manage. I would ship this draft with

.length (#154) and we would have a registration policy of how things
would be
added.

Tim: I am probably against this, I hate optional features as you lead to
SQL.

James: We're talked about SQL before - it doesn't have an IANA registry,
we will
have a controlled mechanised with experts and review, and the document
review
with IESG and IANA will check this. If we do not provide this
implementations
will do it anyway, we think that's inevitable due to the demand, and our

standard will be forked to include desired capability.

Glyn: We already have 30 implementations, so I think it's too late

James: I disagree, we shouldn't set the expectation that all
implementations
have to provide support for all implementations, only the mechanisms for
it. We
already diverge away from existing implementations.

Tim: Do we have someone to write something on this?

Action: Carsten to write an extension proposal to discuss

Draft Status, Existing Issues...

Tim: I'd like to get sense from the group on base draft status?

Carsten: We have 16 issues in Github, most of which can be closed

Actions:

• Glyn to improve associative documentation
• #162 to be closed by the editors
• #161 Carsten to write comment and close
• #117 Tim to close

Next Meeting, AOB

Action: James to send out poll to schedule next interim
Action: James to update milestones