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

[Glyn Normington <[e-mail]>]

> 2. Provide a way to plug in regular expressions (of different flavors)

Let's explore the above option a little further in this separate thread.

If we defined a general way of using jsonpath with a variety of regexp
specs -- basically just ensuring that we can parse a filter's regexps
without consuming more of the surrounding jsonpath than we should --, then
jsonpath would effectively become a template for concrete specifications
such as jsonpath/iregexp, jsonpath/RE2, etc.

This would break the dependency between the jsonpath spec and completion of
iregexp, allowing jsonpath to complete early. It would also allow the
iregexp spec to be revised without having to revise the jsonpath spec.
Another advantage is that it would reduce the cost of implementation in
some cases and thereby increase the adoption of the jsonpath spec.

Our ultimate, interoperable recommendation could still end up being
jsonpath/iregexp, once iregexp is finished. We could do this either by
recommending (or mandating) jsonpath/iregexp in a second version of the
jsonpath spec or we could publish a separate spec tying the two together.

The main problem with this template approach is the reduction in
interoperability among implementations which choose distinct regexp specs.
But an advantage for implementers is that they could simply choose the most
convenient regexp implementation, not have to perform any mapping (which
would include possibly onerous test writing), and get good interoperation
with other jsonpath implementations which make the same choice. I think
this would increase the adoption of jsonpath among implementers.

Another problem with the template approach is that implementers may be
tempted to plug in a convenient regexp implementation without a decent
spec. This would make using that combination more difficult (because of the
need for guesswork on regexp details) and could further limit
interoperation.

Admittedly, this option has several disadvantages, but I don't think we
should necessarily discount it, especially as a stepping-stone to our final
destination.

On Sun, 14 Nov 2021 at 21:15, Carsten Bormann <[e-mail]> wrote:

> 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
>
> --
> JSONpath mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jsonpath
>