Skip to content

Giving "notes" a magic-ectomy #2

@stuartpb

Description

@stuartpb

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 notes alternatives like caveats) 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 notes is 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).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions