Skip to content

Update regex concerns for subschema application #599

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 12, 2018
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
51 changes: 47 additions & 4 deletions jsonschema-core.xml
Original file line number Diff line number Diff line change
Expand Up @@ -538,6 +538,39 @@
</t>
</section>

<section title="Regular Expressions" anchor="regex">
<t>
Keywords MAY use regular expressions to express constraints, or constrain
the instance value to be a regular expression.
These regular expressions SHOULD be valid according to the
<xref target="ecma262">ECMA 262</xref> regular expression dialect.
</t>
<t>
Furthermore, given the high disparity in regular expression constructs support,
schema authors SHOULD limit themselves to the following regular expression
tokens:

<list>
<t>individual Unicode characters, as defined by the <xref
target="RFC8259">JSON specification</xref>;</t>
<t>simple character classes ([abc]), range character classes ([a-z]);</t>
<t>complemented character classes ([^abc], [^a-z]);</t>
<t>simple quantifiers: "+" (one or more), "*" (zero or more), "?" (zero or
one), and their lazy versions ("+?", "*?", "??");</t>
<t>range quantifiers: "{x}" (exactly x occurrences), "{x,y}" (at least x, at
most y, occurrences), {x,} (x occurrences or more), and their lazy
versions;</t>
<t>the beginning-of-input ("^") and end-of-input ("$") anchors;</t>
<t>simple grouping ("(...)") and alternation ("|").</t>
</list>
</t>
<t>
Finally, implementations MUST NOT take regular expressions to be
anchored, neither at the beginning nor at the end. This means, for instance,
the pattern "es" matches "expression".
</t>
</section>

<section title="Extending JSON Schema">
<t>
Additional schema keywords and schema vocabularies MAY be defined
Expand Down Expand Up @@ -1505,8 +1538,9 @@ User-Agent: product-name/5.4.1 so-cool-json-schema/1.0.2 curl/7.43.0
</t>
<t>
Interoperability considerations: See Sections
<xref target="language" format="counter"></xref> and
<xref target="integers" format="counter"></xref> above.
<xref target="language" format="counter"></xref>,
<xref target="integers" format="counter"></xref>, and
<xref target="regex" format="counter"></xref>above.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does this need a space before "above" ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ugh, yes. Fixed in PR #603 if you'd be so kind as to review :-) Thanks for catching it.

</t>
<t>
Fragment identifier considerations: See Section
Expand Down Expand Up @@ -1548,8 +1582,9 @@ User-Agent: product-name/5.4.1 so-cool-json-schema/1.0.2 curl/7.43.0
</t>
<t>
Interoperability considerations: See Sections
<xref target="language" format="counter"></xref> and
<xref target="integers" format="counter"></xref> above.
<xref target="language" format="counter"></xref>,
<xref target="integers" format="counter"></xref>, and
<xref target="regex" format="counter"></xref>above.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here

</t>
<t>
Fragment identifier considerations: See Section
Expand All @@ -1570,6 +1605,14 @@ User-Agent: product-name/5.4.1 so-cool-json-schema/1.0.2 curl/7.43.0
&RFC6901;
&RFC8259;
&ldp;
<reference anchor="ecma262"
target="http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf">
<front>
<title>ECMA 262 specification</title>
<author/>
<date/>
</front>
</reference>
</references>

<references title="Informative References">
Expand Down
33 changes: 4 additions & 29 deletions jsonschema-validation.xml
Original file line number Diff line number Diff line change
Expand Up @@ -172,35 +172,10 @@

<section title="Regular Expressions" anchor="regexInterop">
<t>
Two validation keywords, "pattern" and "patternProperties", use regular
expressions to express constraints, and the "regex" value for the
"format" keyword constrains the instance value to be a regular expression.
These regular expressions SHOULD be valid according to the
<xref target="ecma262">ECMA 262</xref> regular expression dialect.
</t>
<t>
Furthermore, given the high disparity in regular expression constructs support,
schema authors SHOULD limit themselves to the following regular expression
tokens:

<list>
<t>individual Unicode characters, as defined by the <xref
target="RFC8259">JSON specification</xref>;</t>
<t>simple character classes ([abc]), range character classes ([a-z]);</t>
<t>complemented character classes ([^abc], [^a-z]);</t>
<t>simple quantifiers: "+" (one or more), "*" (zero or more), "?" (zero or
one), and their lazy versions ("+?", "*?", "??");</t>
<t>range quantifiers: "{x}" (exactly x occurrences), "{x,y}" (at least x, at
most y, occurrences), {x,} (x occurrences or more), and their lazy
versions;</t>
<t>the beginning-of-input ("^") and end-of-input ("$") anchors;</t>
<t>simple grouping ("(...)") and alternation ("|").</t>
</list>
</t>
<t>
Finally, implementations MUST NOT take regular expressions to be
anchored, neither at the beginning nor at the end. This means, for instance,
the pattern "es" matches "expression".
Keywords that use regular expressions, or constrain the instance value
to be a regular expression, are subject to the interoperability
considerations for regular expressions in the
<xref target="json-schema">JSON Schema Core</xref> specification.
</t>
</section>

Expand Down