Deprecation-detection Schematron generation?

[wendellpiez]

User Story:

Metaschema supports marking its models as 'deprecated' but these currently have no practical impact for validations against schemas (such as XSD or JSON Schema) produced using those models.

This tool would help plug this gap.

Note that an implementation is going to require semver comparison (see below).

See https://github.com/usnistgov/metaschema/blob/a36f579e1e30abb2263895242cdbd2cf4bd29513/schema/xml/metaschema.xsd#L640 and OSCAL metaschemas for examples.

But (at least) two forms are possible:

• Any deprecation is reported as 'deprecated in (version)'
• The version is checked - it is not reported if stated document version precedes deprecation version

i.e. a distinction between checking 'is currently deprecated' and 'was already deprecated then'. The implication being that the latter is what is asked for, and the former is what people really want. So they need to be able to have either, and the choice.

This suggests an as-of that indicates a version, perhaps also accepting doc-version and current-version as an alternative to stating a version? With current-version as the default (reporting everything deprecated).

This way you can turn of the messages coming from deprecation after any version in which you aren't interested, including any version after the document version.

Goals:

A metaschema now includes indicators that features are being deprecated, while remaining nominally valid (in many cases until removal in a backward-incompatible release).

This markup could be exploited to create, for a (composed) metaschema (model), a Schematron that would warn about the use (appearance) of deprecated features.

• An XSLT-based pipeline (one or more transformations) producing such a Schematron
• A demonstration (OSCAL or other)
• Unit testing as appropriate

Dependencies:

Semantic version comparison is implemented in https://github.com/usnistgov/xslt3-functions - we need this submodule?

This may or may not be related to #61. Decoupling them could be useful.

Acceptance Criteria

• All website and readme documentation affected by the changes in this issue have been updated. Changes to the website can be made in the docs/content directory of your branch.
• A Pull Request (PR) is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR.
• The CI-CD build process runs without any reported errors on the PR. This can be confirmed by reviewing that all checks have passed in the PR.