Subject: [Jsonpath] WG adoption draft-bormann-jsonpath-iregexp-02

From: Tim Bray <[email-masked]>
Date: Tue, 18 Jan 2022 10:16:52 -0800

Co-chair hat on: At our interim meeting earlier today, we got a strong
sense that the jsonpath WG has consensus in favor of allowing regular
expressions in jsonpath filters, but that for this to be useful, the flavor
of regexps needs to be specified precisely, and that flavor should be
limited enough in scope to allow interoperation across as many as possible
different regex libraries.

Carsten Bormann has done the work of proposing such a small-scope
regexp specification. The draft may be read at
https://www.ietf.org/archive/id/draft-bormann-jsonpath-iregexp-02.html
and is on GitHub at https://github.com/cabo/iregexp

If you have any issues to raise or objections to this, please let the WG
know.

---

From: Michael Kay <[email-masked]>
Date: Tue, 18 Jan 2022 18:30:51 +0000

I would suggest referencing XSD 1.1 rather than XSD 1.0.

The only difference in the regex capabilities is that XSD 1.1 fixes some bugs in the specification. It would be a shame to have a normative reference to a spec with known bugs.

Michael Kay
Saxonica

> On 18 Jan 2022, at 18:16, Tim Bray <[email-masked]> wrote:
> 
> Co-chair hat on: At our interim meeting earlier today, we got a strong sense that the jsonpath WG has consensus in favor of allowing regular expressions in jsonpath filters, but that for this to be useful, the flavor of regexps needs to be specified precisely, and that flavor should be limited enough in scope to allow interoperation across as many as possible different regex libraries. 
> 
> Carsten Bormann has done the work of proposing such a small-scope regexp specification. The draft may be read at https://www.ietf.org/archive/id/draft-bormann-jsonpath-iregexp-02.html <https://www.ietf.org/archive/id/draft-bormann-jsonpath-iregexp-02.html>
> and is on GitHub at https://github.com/cabo/iregexp <https://github.com/cabo/iregexp>
> 
> If you have any issues to raise or objections to this, please let the WG know.
> -- 
> JSONpath mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jsonpath

---

From: Greg Dennis <[email-masked]>
Date: Tue, 18 Jan 2022 20:19:01 +0000 (UTC)

This is great.  I've also opened a discussion (https://github.com/json-schema-org/community/discussions/136) with the JSON Schema group to see if they're open to joining this effort and eventually adopting this small-scope spec for that functionality as well.
Greg

    On Wednesday, January 19, 2022, 07:17:17 AM GMT+13, Tim Bray <[email-masked]> wrote:  
 
 Co-chair hat on: At our interim meeting earlier today, we got a strong sense that the jsonpath WG has consensus in favor of allowing regular expressions in jsonpath filters, but that for this to be useful, the flavor of regexps needs to be specified precisely, and that flavor should be limited enough in scope to allow interoperation across as many as possible different regex libraries. 
Carsten Bormann has done the work of proposing such a small-scope regexp specification. The draft may be read at https://www.ietf.org/archive/id/draft-bormann-jsonpath-iregexp-02.htmland is on GitHub at https://github.com/cabo/iregexp

If you have any issues to raise or objections to this, please let the WG know.-- 
JSONpath mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jsonpath

---

From: Tim Bray <[email-masked]>
Date: Wed, 19 Jan 2022 09:06:51 -0800

Oh, an update: I sent a big PR yesterday reorganizing the draft while
preserving more or less all of its content:
https://github.com/cabo/iregexp/pull/1 and I just saw Carsten merged it.
For convenience, I've attached what the HTML now looks like.

On Tue, Jan 18, 2022 at 12:19 PM Greg Dennis <[email-masked]> wrote:

> This is great.  I've also opened a discussion (
> https://github.com/json-schema-org/community/discussions/136) with the
> JSON Schema group to see if they're open to joining this effort and
> eventually adopting this small-scope spec for that functionality as well.
>
> Greg
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 19 Jan 2022 18:10:59 +0100

On 2022-01-19, at 18:06, Tim Bray <[email-masked]> wrote:
> 
> Oh, an update: I sent a big PR yesterday reorganizing the draft while preserving more or less all of its content: https://github.com/cabo/iregexp/pull/1 and I just saw Carsten merged it.  For convenience, I've attached what the HTML now looks like.

FYI: Due to the magic of Martin Thomson’s I-D-Template, you can always current HTML at

https://cabo.github.io/iregexp/draft-bormann-jsonpath-iregexp.html

… which is referenced from the README as “Editor’s copy”.

I’ll push a commit with a few minor consistency edits soon.
Then on to Michael Kay’s comment, which is very good, but complicated in its consequences.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 20 Jan 2022 00:32:04 +0100

> The only difference in the regex capabilities is that XSD 1.1 fixes some bugs in the specification. It would be a shame to have a normative reference to a spec with known bugs.

I have made a pull request that references XSD 1.1 as well.

https://github.com/cabo/iregexp/pull/3

This PR recognizes the fact that XSD 1.0 is more widely implemented than XSD 1.1.
Both RFC 7950 and RFC 8610 reference only XSD 1.0 (and imply that an astute consumer of any specification will handle the errata with that, especially if they have been known for a decade and more).
Potentially giving the impression that I-Regexp somehow needs XSD 1.1, which brings a lot of baggage that is not relevant here, would be highly misleading.

Grüße, Carsten

---

From: Michael Kay <[email-masked]>
Date: Thu, 20 Jan 2022 00:04:31 +0000

> This PR recognizes the fact that XSD 1.0 is more widely implemented than XSD 1.1.

If we're talking about implementations, then they will have had to fix the bugs in the XSD 1.0 spec, and hopefully in most cases they will have fixed them in the same way as XSD 1.1 fixed them. (However, some XSD 1.0 implementors, notably Microsoft, largely ignored the XSD-defined regex rules and just used an existing regex library.)

But I thought we were talking about specs, not about implementations.

For some of the discussion of bugs, see

https://www.w3.org/Bugs/Public/show_bug.cgi?id=1889

https://www.w3.org/Bugs/Public/show_bug.cgi?id=2019

https://www.w3.org/Bugs/Public/show_bug.cgi?id=2058

https://www.w3.org/Bugs/Public/show_bug.cgi?id=2123

Unfortunately these reference documents which are not publicly accessible.

To the best of my knowledge there are no changes in regex syntax/semantics between XSD 1.0 and 1.1 other than bug fixes.

Michael Kay