Re: [Jsonpath] Comments on I-regexp

[Greg Dennis <[e-mail]>]

Regarding the anchoring comment, we had an extensive discussion about this on https://github.com/ietf-wg-jsonpath/iregexp/issues/15 when JSON Schema (which primarily uses unanchored expressions) was considering this for its normative Regex reference.
It was ultimately decided that anchors were desired for this specification.  I'd be surprised if it's not in the document somewhere.
Greg

Sent from Yahoo Mail on Android 
 
  On Sat, 14 Oct 2023 at 2:04 pm, Michael Kay<mike=[e-mail]> wrote:   Excellent work.

I find it disappointing that the normative reference is to XSD 1.0 rather than 1.1, since the 1.0 spec contains some quite serious bugs fixed in 1.1. The fact that 1.0 is more widely implemented seems irrelevant; indeed it seems harmful, since I-RegExp implementors may turn to XSD 1.0 implementations for guidance, and it is known that XSD 1.0 implementors have found different ways of fixing the bugs in the spec.

I note that there is no mechanism for identifying Unicode characters by their numeric codepoint. This is not needed in XSD, because the XML escape convention (e.g. `&#x10000;`) is available. I can imagine that in other contexts this could make it quite difficult to write readable regexps, unless some host-language escape mechanism is available. Perhaps the RFC should suggest a convention for denoting "visually indistinctive" characters such as NBSP when I-Regexps are used in IETF specifications?

It is stated that the only functionality supported is string matching; it may be worth mentioning, for those unfamiliar with XSD, that this means anchored string matching.

My reading of the ABNF is that standalone hyphens have been restricted to appear at the start or end of a character group. This is a good solution to a problem that has been very troublesome in XSD; it is worth highlighting this as one of the differences from XSD.

Specifying the syntax directly in the RFC, and the semantics by reference to a different specification that uses a different grammar, creates something of a disconnect. Essentially I think you're expected first to check that the I-RegExp parses according to the RFC grammar, then to reparse it according to the XSD grammar, which yields constructs that are referenced in the XSD semantics. The XSD semantics uses terms like CharGroupPart that appear in the XSD grammar but not in the RFC grammar; it also uses terms like quantifier that appear in both grammars but with different definitions. I don't think there are any insuperable problems here but it does make the detail quite hard to follow. Would it be better to lift the semantics out of XSD and into the RFC?

Michael Kay
Saxonica
-- 
JSONpath mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/jsonpath