The opt-in validate option in #634 checks the well-formedness of the terms the parser produces after parsing — IRIs (RFC 3987), language tags (BCP 47), and the lexical space of the common XSD datatypes. Two term dimensions are still unchecked and would round out validate: { terms: true }:
- Blank-node labels — validate the label against the blank-node-label production (
PN_CHARS_BASE / PN_CHARS with the usual first/last-character rules), so a label carrying characters that have no escape mechanism in the Turtle family — whitespace, <, >, ., control characters — is rejected rather than carried through to serialization. The default lexer already constrains the labels it mints, so this is a defence-in-depth / round-trip-safety check for terms that reach the parser's factory (or a downstream writer) from non-grammar sources.
- Literal base direction — where a directional language-tagged literal is produced, validate that the direction is exactly
ltr or rtl. This should compose with the existing version profile: directional language tags are an RDF 1.2 feature, so under version: '1.1' they are already rejected by validate: { version: true }; this check covers well-formedness of the direction value itself where it is permitted.
Suggested implementation
Both checks belong alongside the existing ones in src/Validation.js (e.g. isValidBlankNodeLabel, isValidBaseDirection), wired into the same per-instance method overrides so there is still zero cost when validate is off. Tests go in test/Validation-test.js, and the validate section of the README should list the two added dimensions.
Background
These are the two remaining term dimensions from a term-well-formedness review (tracked there as M4 — blank-node labels and M5 — language tag / base direction; the language-tag half is already covered by #634). They are input-well-formedness / GIGO concerns rather than default-hot-path guards, so the opt-in validation layer added in #634 is their natural home rather than a fail-closed throw in the writer's default path.
The opt-in
validateoption in #634 checks the well-formedness of the terms the parser produces after parsing — IRIs (RFC 3987), language tags (BCP 47), and the lexical space of the common XSD datatypes. Two term dimensions are still unchecked and would round outvalidate: { terms: true }:PN_CHARS_BASE/PN_CHARSwith the usual first/last-character rules), so a label carrying characters that have no escape mechanism in the Turtle family — whitespace,<,>,., control characters — is rejected rather than carried through to serialization. The default lexer already constrains the labels it mints, so this is a defence-in-depth / round-trip-safety check for terms that reach the parser'sfactory(or a downstream writer) from non-grammar sources.ltrorrtl. This should compose with the existingversionprofile: directional language tags are an RDF 1.2 feature, so underversion: '1.1'they are already rejected byvalidate: { version: true }; this check covers well-formedness of the direction value itself where it is permitted.Suggested implementation
Both checks belong alongside the existing ones in
src/Validation.js(e.g.isValidBlankNodeLabel,isValidBaseDirection), wired into the same per-instance method overrides so there is still zero cost whenvalidateis off. Tests go intest/Validation-test.js, and thevalidatesection of the README should list the two added dimensions.Background
These are the two remaining term dimensions from a term-well-formedness review (tracked there as M4 — blank-node labels and M5 — language tag / base direction; the language-tag half is already covered by #634). They are input-well-formedness / GIGO concerns rather than default-hot-path guards, so the opt-in validation layer added in #634 is their natural home rather than a fail-closed throw in the writer's default path.