bom and non-ascii are POSITIONAL FACTS, not errors.
This predicate exists so a renderer cannot give them error severity by
accident, and it is a guard rather than a comment because the failure it
prevents is silent and user-facing: /system identity set name="router-🚀"
(commands/explain/examples.md example 22) is a perfectly legal command whose
value is non-ASCII by design. Failing it under --fail-on error would be a
false positive on correct input, and RouterOS comments and string values carry
non-ASCII routinely.
What these two regions actually record is where the byte-count-preserving
normalization stood in for bytes the analyzer cannot read — i.e. the spans a
consumer needs in order to map back to the original text. That is a coordinate
fact. The other structural codes mark input the analyzer could not structurally
resolve, which is a different thing.
hasStructuralDefect is where that distinction is enforced, so a UTF-8
comment can never flip a document's write tristate to unknown.
bomandnon-asciiare POSITIONAL FACTS, not errors.This predicate exists so a renderer cannot give them error severity by accident, and it is a guard rather than a comment because the failure it prevents is silent and user-facing:
/system identity set name="router-🚀"(commands/explain/examples.mdexample 22) is a perfectly legal command whose value is non-ASCII by design. Failing it under--fail-on errorwould be a false positive on correct input, and RouterOS comments and string values carry non-ASCII routinely.What these two regions actually record is where the byte-count-preserving normalization stood in for bytes the analyzer cannot read — i.e. the spans a consumer needs in order to map back to the original text. That is a coordinate fact. The other structural codes mark input the analyzer could not structurally resolve, which is a different thing.
hasStructuralDefect is where that distinction is enforced, so a UTF-8 comment can never flip a document's write tristate to
unknown.