Actually ... an all-XSLT metaschema-based validator ...?

[wendellpiez]

User Story:

We have #61 planned, but Metaschema (especially wrt constraints) has changed since the earlier work was done ... while questions come up regarding Schematron and its implementation(s).

Another very interesting input we have is the demonstration here: https://pages.nist.gov/oscal-tools/demos/csx/validator/

What would be awesome would be a processor that combines these feature sets.

It could run either in a browser like the demo, or CL/CI/CD via scripting.

A secondary benefit of this approach is that it serves as a distinct implementation of a Metaschema-based validator at least for XML and thus as validation/testing for the Metaschema concept itself.

Goals:

Not a complete implementation, but a working model with interfaces -

• Pull out and consolidate code bases
• Set up a pipeline that consumes metaschema and delivers an XSLT for testing instances
  • Demonstrate production of a standalone XSLT that delivers SVRL and/or plain text
• Set up or plan a pipeline embedding the prior pipeline in a test harness with metaschema example plus instances
• Similarly, XSpec the testing of instances (both good and known-bad) with an XSLT for a testing metaschema
• Scope further work to be done, including
  • completion of feature set
  • 'completion' or publication-readiness of test set(s)
  • documentation and deployment support - environments such as oXygen, VSCode?
  • SaxonJS deployment? Pages site?
  • consideration of non-XML formats
  • consideration of architecture - could this be extensible (callback library for user-provided XSLT modules)

Non-goal

Even if we happen to make one for testing, the goal is not a processor that can read from a metaschema dynamically and provide validation of instances on that basis, but rather the production of a static XSLT that can support such a runtime, when applied directly to an instance or instances. (A dynamic processor can be a follow-on if/as wanted.)

Dependencies:

None known except prior work as documented above.

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.
• Follow-on Issues have been created as appropriate.
• 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.