[Jsonpath] #70 Regexps (was: Re: Draft minutes, consensus points, and actions from IETF 112)

[Carsten Bormann <[e-mail]>]

On 2021-11-14, at 12:35, James <[e-mail]> wrote:
> 
> * #70 - Have discussion on list with known options

As a reminder, my slides had these options (renumbered for easier reference, and expanded a bit):

1. Select (define) one regular expression flavor
2. Provide a way to plug in regular expressions (of different flavors)
3. No regexps in base RFC (but keep an extension point)

1. further splits into:

1a. Select *a version of* ECMAScript (parsing/searching RE)
1b. Select W3C XSD RE (matching RE)
1c. Build "modest subset" (e.g., iregexp)

Since we don’t have a consensus or even a majority among the implementations, we are free to do the right thing, if we can pull that off.

As you know, I have been exploring 1c.

I submitted an updated version -01 of draft-bormann-jsonpath-iregexp.
As in -00, I’m using W3C XSD RE as a base, as these are actual regular expressions, amenable to implementation techniques that are less susceptible to DoS problems than the Perl/PCRE/ECMAscript dialect.

Apart from character class subtraction and the exact semantics of Multi-Character escapes (\s \d \w etc., outside and inside of character class expressions), W3C XSD RE are pretty much a consensus subset of the various regular expression dialects, except that they are in the form of matching expressions (no anchors needed) instead of parsing expressions.  

I believe the spec should have conversion instructions for implementers that just want to use the regexp engine they happen to have handy.  Because of the consensus subset nature of W3C XSD RE, these instructions are relatively straightforward (copy, and surround by the anchors the target flavor happens to use).

I tried to add conversion instructions for Multi-Character escapes (\s \d \w and \S \D \W, leaving out the \c and \i that nobody except W3C has).
As you can see when looking at the diff, the result is not pretty when it comes to double negation in character classes.  Maybe a pathological case, but a bit of a trap, and maybe not that useful anyway as the W3C semantics is quite different from the PCRE ones.
So I’m leaning towards a -02 that does not have Multi-Character escapes.
(None of the regexps I found in RFCs uses them, and not having them also happens to be pretty much what the json-schema.org drafts seem to converge at.)

Grüße, Carsten

Status:   https://datatracker.ietf.org/doc/draft-bormann-jsonpath-iregexp/
Html:     https://www.ietf.org/archive/id/draft-bormann-jsonpath-iregexp-01.html
Diff:     https://www.ietf.org/rfcdiff?url2=draft-bormann-jsonpath-iregexp-01