docs: document validation scope and external term validation - #622
Merged
Conversation
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
jeswr
commented
Jul 2, 2026
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
jeswr
commented
Aug 23, 2026
jeswr
commented
Aug 23, 2026
jeswr
commented
Aug 23, 2026
jeswr
commented
Aug 23, 2026
jeswr
commented
Aug 23, 2026
jeswr
commented
Aug 23, 2026
jeswr
commented
Aug 23, 2026
Contributor
There was a problem hiding this comment.
Pull request overview
This PR clarifies N3.js’s validation responsibilities by documenting that parsing validates per-format grammar/syntax (not RDF term well-formedness), and that writing serializes provided terms as-is—bridging the expectation gap referenced in #308 and writer-side issues (#329/#383).
Changes:
- Adds a Validation subsection under Compatibility describing what the parser/writer do and do not validate.
- Provides a short stream-based Transform example for post-parse term validation using external validators.
- Links to proposed parser-level opt-in validation modes (PR #634).
Suppressed comments (1)
README.md:514
- Several typos/grammar issues in this paragraph ("snipped"/"occuring"), and
termTypeslooks like an accidental code identifier (RDF/JS usestermType; here you likely mean "term types"). Also, the snippet requires additional packages but doesn't mention installing them.
The following code snipped shows how to validate that NamedNodes and Literals are validly formed. Depending on your application you may wish to apply further validation: such as ensuring that nested Quad terms are valid in RDF 1.2, and ensuring that `termTypes` are only occuring in the positions that is valid for RDF 1.1 and RDF 1.2.
```JavaScript
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Contributor
|
🎉 This PR is included in version 2.2.12 🎉 The release is available on: Your semantic-release bot 📦🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Recurring issues (#308, and the writer side in #329/#383) stem from the same expectation gap: N3.js validates per-format grammar, not the terms themselves. This adds a short Validation subsection under Compatibility stating what the parser guarantees, what it deliberately does not check (RFC 3987 well-formedness beyond the grammar, unresolved relative IRIs without
baseIRI, literal value vs datatype, BCP 47 language tags, and that the writer trusts its input terms), and a compact validating-Transform snippet composingvalidate-iri,rdf-validate-datatype, andbcp-47for users who need term validation.All claims and the snippet were verified against n3@2.1.0 and current
main(e.g.<http://example.org/%ZZ>and"abc"^^xsd:integerparse; the snippet rejects both).Refs #308
cc @jeswr