Skip to content

Explain why plain name fragments are as they are #1293

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.

Sign up for GitHub

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 4 commits into from
Oct 4, 2022
Merged

Explain why plain name fragments are as they are #1293

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
9e81619
Explain why plain name fragments are as they are
handrews Sep 18, 2022
f367d47
Reorganize plain name fragment requirements
handrews Sep 23, 2022
903240e
Fix singular to plural
handrews Sep 23, 2022
c4aed5e
Remove stray empty paragraph.
handrews Oct 2, 2022
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
25 changes: 17 additions & 8 deletions jsonschema-core.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,6 +12,7 @@
<!ENTITY RFC8288 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8288.xml">
<!ENTITY ldp SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml4/reference.W3C.REC-ldp-20150226.xml">
<!ENTITY fragid-best-practices SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml4/reference.W3C.WD-fragid-best-practices-20121025.xml">
<!ENTITY xptr-framework SYSTEM "https://bib.ietf.org/public/rfc/bibxml4/reference.W3C.REC-xptr-framework-20030325.xml">
]>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
Expand Down Expand Up @@ -513,7 +514,18 @@
Per the W3C's
<xref target="W3C.WD-fragid-best-practices-20121025">best practices for fragment identifiers</xref>,
plain name fragment identifiers in "application/schema+json" are reserved for referencing
locally named schemas. All fragment identifiers that do
locally named schemas.
</t>
<t>
Plain name fragments MUST start with a letter ([A-Za-z]) or underscore ("_"),
followed by any number of letters, digits ([0-9]), hyphens ("-"),
underscores ("_"), and periods ("."). This matches the US-ASCII part of XML's
<xref target="xml-names">NCName production</xref>, which allows for compatibility
with the recommended plain name <xref target="W3C.REC-xptr-framework-20030325">syntax</xref> for
XML-based media types.
</t>
<t>
All fragment identifiers that do
not match the JSON Pointer syntax MUST be interpreted as
plain name fragment identifiers.
</t>
Expand All @@ -522,8 +534,6 @@
"application/schema+json" document are specified
in the <xref target="anchor">"$anchor" keyword</xref> section.
</t>
<t>
</t>
</section>

<section title="General Considerations">
Expand Down Expand Up @@ -1455,11 +1465,9 @@
need for "$dynamicAnchor".
</t>
<t>
If present, the value of this keyword MUST be a string and MUST start with
a letter ([A-Za-z]) or underscore ("_"), followed by any number of letters,
digits ([0-9]), hyphens ("-"), underscores ("_"), and periods (".").
This matches the US-ASCII part of XML's
<xref target="xml-names">NCName production</xref>.
If present, the value of these keywords MUST be a string and MUST conform
to the plain name fragment identifier syntax defined in section
<xref target="fragments" format="counter"></xref>.
<cref>
Note that the anchor string does not include the "#" character,
as it is not a IRI-reference. An "$anchor": "foo" becomes the
Expand Down Expand Up @@ -3555,6 +3563,7 @@ https://example.com/schemas/common#/$defs/allOf/1
&RFC7231;
&RFC8288;
&fragid-best-practices;
&xptr-framework;
<reference anchor="json-schema-validation">
<front>
<title>JSON Schema Validation: A Vocabulary for Structural Validation of JSON</title>
Expand Down