-
Notifications
You must be signed in to change notification settings - Fork 0
Open
Description
Since 56928a1, any additional property called notes gets completely skipped over by the validator, instead of throwing an error.
This is a clumsy fix for the way that lots of profiles have freeform notes in arbitrary locations, and the schema doesn't.
More importantly, it's preventing the full realization of opws/opws-dataset#12: it's still possible (and I'm pretty sure, in at least one case in the current dataset, present) for notes to be present and not in the form of a description list.
There are a few angles this problem can be attacked from:
- Integrating notes (including
notesalternatives likecaveats) intelligently into future schema versions, so they can be validated normally, and can also only be in a few positions with well-defined use/presentation semantics. This follows the legacy of Diversifying notes for complex remarks and proposed specifications opws-dataset#137, and is the direction I ultimately want to see a solution in. - Integrating notes clumsily into future schema versions, using pre-processing (ie. an extension of the copldots processing that YAML uses now) to attach them to every object definition in the schema. I don't like this, because it takes an existing problem ("arbitrary data can appear anywhere in the structure with no clear way to handle it") and institutionalizes it instead of trying to address it. In its current form, where
notesis not part of the schema and is only sort of tacitly ignored in the validator, it exists in a proper sort of quasi-legitimate state that, while not good, hasn't gone too far into being irreconcilable. - Adding description-list validation to the special exception, so even if notes are present, they can still fail if they're not in the right structure. This would take a bit of work, and I'm uneasy about it ,because it feels as much like a step down the bad road (building infrastructure around thoughtlessly-scattered notes) as a step down the good road (making notes clearly-defined and as rigorously-structured as the rest of profiles).
- Putting notes exceptions behind a flag/option, either on or off by default. This'll probably be called for as things transition to whatever solution ultimately ends up falling into place, to test schemas as they move toward it, toggling into the new behavior and out of the old one (and/or vice-versa).
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels