Datatype proposed design

[nikitawootten-nist]

Committer Notes

A toy implementation of the Datatype and Item concepts of the Metaschema. This implementation only implements a string datatype and corresponding adapter. Please pay extra attention to the AbstractDatatypeAdapter's shape.

Be sure to check some caveats here: https://github.com/usnistgov/metaschema-node/pull/34#issuecomment-1310852758

All Submissions:

• [x] Have you selected the correct base branch per Contributing guidance?
• [x] Have you set "Allow edits and access to secrets by maintainers"?
• [x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• [x] Have you squashed any non-relevant commits and commit messages? [instructions]
• [x] Do all automated CI/CD checks pass?

Changes to Core Features:

• [x] Have you added an explanation of what your changes do and why you'd like us to include them?
• [x] Have you written new tests for your core changes, as applicable?
• [x] Have you included examples of how to use your new feature(s)?

[nikitawootten-nist]

This design has a few caveats:

• Typescript doesn't support abstract static members, making a DatatypeAdapter's Item generic parameter little more then a type annotation... The adapter must separately implement a name field. There is a workaround, but it's unmaintainable at best: https://stackoverflow.com/a/43723730 Update 12/29/22: Adapters (now called Serializers) are no longer in charge of naming themselves, this is now the job of a Provider class (see the ADR entry for details)
• Jest (the project's test runner) has a problem with node-fetch, forcing me to add --force-exit for now
• Since metaschema datatype fields are lazy-evaluated, the OSCALMetaschema.spec.ts test passes even though the MetaschemaProvider only contains a "string" type. Calling getDatatypeAdapter() on any non-string fields or flags would trigger an error.
• Currently, datatype saving or loading is not tested, in order to test realistically a whole dom or binding implementation of Metaschema instances would have to be created. This could very well be the next order of business in order to create an "end-to-end" Metaschema test. Update 12/29/22: An ADR entry with a proposed design for a DOM-based parser has been created has been created along with this PR.