docs/ir-design.md §5.3 says encoding "attaches at the scalar definition or overrides at the property — property wins", and ir/constraints.go says the same of Encoding ("Property encoding overrides scalar encoding") and of XMLHints ("per-use overrides; property wins"). Both read as whole-struct: a property that sets Encoding{Name: "base64"} replaces the scalar's Encoding entirely.
Encoding now carries MediaType and, since #440, Schema — the decoded shape of the value. Under a whole-struct override a property that only renames the encoding drops the scalar's Schema and MediaType, though the property never said anything about either. XMLHints has the same shape: a property setting only Name would drop the type's Namespace/Prefix.
No consumer implements the override yet, so nothing is wrong today; the rule is what a first emitter would read. Two ways to settle it:
- Per-field: a property's
Encoding/XMLHints overrides field by field, unset fields inheriting the scalar's. Compilers write only what the position declared.
- Whole-struct, stated: a property
Encoding replaces the scalar's entirely, and a compiler that means to keep the scalar's Schema copies it onto the property.
Either way §5.3 and the two doc comments should say which. Raised in review of #464 and deliberately left out of it, since it is an IR semantic decision rather than a fix.
docs/ir-design.md§5.3 says encoding "attaches at the scalar definition or overrides at the property — property wins", andir/constraints.gosays the same ofEncoding("Property encoding overrides scalar encoding") and ofXMLHints("per-use overrides; property wins"). Both read as whole-struct: a property that setsEncoding{Name: "base64"}replaces the scalar'sEncodingentirely.Encodingnow carriesMediaTypeand, since #440,Schema— the decoded shape of the value. Under a whole-struct override a property that only renames the encoding drops the scalar'sSchemaandMediaType, though the property never said anything about either.XMLHintshas the same shape: a property setting onlyNamewould drop the type'sNamespace/Prefix.No consumer implements the override yet, so nothing is wrong today; the rule is what a first emitter would read. Two ways to settle it:
Encoding/XMLHintsoverrides field by field, unset fields inheriting the scalar's. Compilers write only what the position declared.Encodingreplaces the scalar's entirely, and a compiler that means to keep the scalar'sSchemacopies it onto the property.Either way §5.3 and the two doc comments should say which. Raised in review of #464 and deliberately left out of it, since it is an IR semantic decision rather than a fix.