Don't duplicate content in XML schemas

[bradh]

User Story:

As an OSCAL schema consumer (tool writer), I would like XSDs that do not have duplicate content. For example, I don't want the Catalog schema and Profile schema to both describe Metadata.

Goals:

I want to automatically convert the schemas to class definitions (e.g. with JAXB). If I have two schemas with the same content, I have to use two separate namespaces, and I end up with two different (yet equivalent) classes for anything duplicated. That makes my code ugly (because now I have to use the full namespace + class name) and makes it harder to share the handler code.

Dependencies:

None.

Acceptance Criteria

Be able to generate a single class for each single concept in the schemas.

Implementation Notes

I think what I'm asking is that the metaschema translation keeps the shared parts (from https://github.com/usnistgov/OSCAL/blob/master/src/metaschema/oscal_metadata_metaschema.xml) as a separate XSD, and the using XSDs just import that.

[wendellpiez]

We've discussed this a little and it represents an interesting (and somewhat challenging) set of problems. Flagging @david-waltermire-nist (who has a better understanding than myself) so we can consider options. One might be a way to produce a single synthetic schema for models that are meant to be used together. There are probably others. Because it is the problem is foundational and others will have it (at least anyone using JAXB), this issue needs to be pushed up.

Flagging as Milestone 2 at least for purposes of planning.

NB: some elements such as metadata and its contents are expected to be used similarly across catalog and profile models. Others are not (group comes to mind). This does not mean there are not ways to reconcile them.

[david-waltermire]

The Metaschema approach causes duplication, but we are working on code generation based on the Metaschema infoset that can generate a common set of shared classes across models for shared objects. From what you wrote above, I believe this will address your concerns around data binding.

@bradh Does this address your concerns? If so, I'd like to close this issue.

[bradh]

I'd prefer to be able to build from the XSDs ( and not everyone wants Java...), but once the utility class generation is available, I can live with that as an alternative solution to the problem.

[wendellpiez]

We can also revisit XSD design optimization. The next version Metaschema XSDs are a bit cleaner, and there may also be more that can be done (as Metaschema matures).