jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-jsonpath-iregexp

Commentary: Clarifications in conversion to platform regexps . 
 Looks plausible but I do n't know these regexps well enough to approve .
Envelope the result in "^" and "$".
Envelope the result in "^(?:" and ")$".
The ECMAScript regexp is to be interpreted as a Unicode pattern ("u"
flag; see Section 21.2.2 "Pattern Semantics" of ECMA-262).
Enclose the regexp in "\A" and "\z".
Enclose the regexp in "\A(?:" and ")\z".
Draft: draft-ietf-jsonpath-iregexp

Commentary: Signed - off - by :   < on our email thread with  , and a couple of minor editorial touch - ups . 
 LGTM , thanks .
I-Regexp does not provide advanced regexp features such as capture
groups, lookahead, or backreferences.  It supports only a Boolean
matching capability, i.e., testing whether a given regexp matches a
given piece of text.
I-Regexp is a subset of XSD regexps XSD-2.
This document includes rules for converting I-Regexps for use with
several well-known regexp libraries.
I-Regexp does not provide advanced regular expression features such
as capture groups, lookahead, or backreferences.  It supports only a
Boolean matching capability, i.e., testing whether a given regular
expression matches a given piece of text.
I-Regexp is a subset of XSD regular expressions XSD-2.
This document includes guidance for converting I-Regexps for use with
several well-known regular expression idioms.
A brief survey of published RFCs yielded the regexp patterns in
Appendix A (with no attempt at completeness).  With certain
exceptions as discussed there, these should be covered by I-Regexps,
both syntactically and with their intended semantics.
The editors of this document conducted a survey of the regexp syntax
used in published RFCs.  All examples found there should be covered
by I-Regexps, both syntactically and with their intended semantics.
The exception is the use of multi-character escapes, for which
workaround guidance is provided in mapping.
The material in this section is non-normative, provided as guidance
to developers who want to use I-Regexps in the context of other
regular expression dialects.
Common multi-character escapes (MCEs), and character classes built
around them, which are not supported in I-Regexp, can usually be
replaced as shown in tbl-sub.
Note that the semantics of "\d" in XSD regular expressions is that of
"\p{Nd}"; however, this would include all Unicode characters that are
digits in various writing systems, which is almost certainly not what
is required in IETF publications.
The construct "\p{IsBasicLatin}" is essentially a reference to legacy
ASCII, it can be replaced by the character class "[\u0000-\u007f]".
Draft: draft-ietf-jsonpath-iregexp

Commentary: I think it is better to support script names than block names for and . Unicode block names are not supported by regexp implementations an interoperable way . Block names as specified in allow ASCII alpha - numerics , hyphens and spec . Unicode says these names are supposed to be matched using ( which says to ignore case , whitespace , underscore ,  , and any initial prefix string " is " ) . But implementations do n't do this and compare names using a wide variety of different rules ( as partially described by " Unicode blocks " section of https://www.regular- ) . Usage of block names can easily be replaced by ranges . Furthermore , block names are not covered by the Unicode stability policy . Scripts names do n't have such a wide range of characters ( there are also 4 - char short script names ) and scripts are generally preferable to blocks for regexps as explained here : Script is in the minimal list of properties that Unicode requires but block is not 
 Thank you ! Very useful input . We are having an interim meeting ( per web conference ) of the JSONPath WG at this very moment ; I 'll look at this later today . 
 I just looked again at XSD and see that sadly it does n't support scripts in . Every major regex implementation that I am aware of that does Unicode and does support scripts ( Go , PCRE ,  , C # , Ruby ) . So if XSD compatibility is crucial ( not sure why it would be at this point ) , my suggestion would be just to get rid of blocks . One could argue that supporting only the general category in is consistent with not supporting character set intersection / difference : once you have multiple things ( e.g. script and category ) , you really need to be able to have intersections / differences of them .
This is essentially XSD regexp without character class subtraction
and multi-character escapes such as "\s", "\S", and "\w".
This is essentially XSD regexp without character class subtraction,
without multi-character escapes such as "\s", "\S", and "\w", and
without Unicode blocks.
Not all regexp implementations support accesses to Unicode tables
that enable executing on constructs such as "\p{IsCoptic}",
although the "\p"/"\P" feature in general is now quite widely
available.  While in principle it's possible to translate these
into codepoint-range matches, this also requires access to those
tables.  Thus, regexp libraries in severely constrained
environments may not be able to support I-Regexp conformance.
Not all regexp implementations support accesses to Unicode tables
that enable executing constructs such as "\p{Nd}", although the
"\p"/"\P" feature in general is now quite widely available.  While
in principle it's possible to translate these into character-class
matches, this also requires access to those tables.  Thus, regexp
libraries in severely constrained environments may not be able to
support I-Regexp conformance.
Draft: draft-bormann-jsonpath-iregexp

Commentary: Thanks ! ( This was two minutes after the deadline :-)
expensive attacked controlled regexp.
expensive attacker-controlled regexp.
Draft: draft-bormann-jsonpath-iregexp

Commentary: This has had the motivation and background material moved into new sections after the syntax and semantics . The opening section have been RFC - i - fied a bit , with one MUST each for syntax and semantics .
"Regular expressions" (regexps) are a set of related, widely
implemented pattern languages used in data modeling formats and query
languages that is available in many dialects.  This specification
defines an interoperable flavor of regexps, I-Regexp.
The present version -02 of this document is a more streamlined update
of the original trial balloon, meant to determine whether this
approach is useful for the JSONPath WG.
This document specifies I-Regexp, a flavor of regular expressions
that is limited in scope with the goal of interoperation across many
different regular-expression libraries.
The present specification defines an interoperable regular expression
flavor, I-Regexp.
This document uses the abbreviation "regexp" for regular expression.
"I-Regexp" is used as a noun meaning a character string which
conforms to the requirements in this specification; the plural is
"I-Regexps".
I-Regexp does not provide advanced regexp features such as capture
groups or backreferences.  It supports only a Boolean matching
capability, i.e. testing whether a given regexp matches a given piece
of text.
I-Regexp is a subset of XSD regexps.
This document includes rules for converting I-Regexps for use with
several well-known regexp libraries.
An I-Regexp MUST conform to the ABNF specification in iregexp-abnf.
This is essentially XSD regexp without character class subtraction
and multi-character escapes.
This syntax is a subset of that of XSD2.  Implementations which
interpret I-Regexps MUST yield Boolean results as specified in XSD2.
The present specification defines an interoperable regexp flavor for
matching, I-Regexp.  This flavor is a subset of XSD regexps.  It also
comes with defined rules for converting the regexp into common
parsing regexp dialects.
The syntax of I-Regexp is defined by the ABNF specification in
iregexp-abnf.
This syntax is a subset of that of XSD2; the semantics of all the
constructs allowed by this ABNF grammar are the same as those in
XSD2.
About a third of the complexity of this ABNF grammar comes from going
into details on the Unicode IsCategory classes.  Additional
complexity stems from the way hyphens can be used inside character
classes to denote ranges; the grammar deliberately excludes
questionable usage such as "/[a-z-A-Z]/".