Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Giving "notes" a magic-ectomy #2

Open
stuartpb opened this issue Mar 3, 2017 · 0 comments
Open

Giving "notes" a magic-ectomy #2

stuartpb opened this issue Mar 3, 2017 · 0 comments

Comments

@stuartpb
Copy link
Member

stuartpb commented Mar 3, 2017

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).
stuartpb added a commit that referenced this issue Nov 15, 2017
This removes the special case for filtering out .notes, which was
never specified in the v0.1 schema, but was considered "valid"
as a compromise with the existing data. In v0.2, most of the uses
for .notes are covered in new properties that *are* specified as
part of the schema: see opws/opws-schemata#1.

To validate documents that would have been previously considered
valid under this exemption, strict schema adherence must be disabled
with the `--loose` option. (Note that this will ignore any *other*
properties that are not defined by the schema as well.)

This closes issue #2.
stuartpb added a commit that referenced this issue Nov 15, 2017
This removes the special case for filtering out .notes, which was
never specified in the v0.1 schema, but was considered "valid"
as a compromise with the existing data. In v0.2, most of the uses
for .notes are covered in new properties that *are* specified as
part of the schema: see opws/opws-schemata#1.

To validate documents that would have been previously considered
valid under this exemption, strict schema adherence must be disabled
with the `--loose` option. (Note that this will ignore any *other*
properties that are not defined by the schema as well.)

This closes issue #2.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant