import relationships between core, common, and extension schemas

[joshualubell]

I'm confused about the respective roles of the "core" and "common" schemas. If I understand the PowerPoint slides correctly, "core" definitions are globally applicable whereas "common" definitions apply to some, but not all, extensions.

However, the "core" schema imports the "common" schema. Why is this the case?

Unless I'm missing something, it would make more sense to me if "core" did not import
common". Then all extensions would could"core", and extensions wishing to leverage the "common" definitions could also import "common"

[wendellpiez]

Josh, that stuff is out of date - everything current is in the 'develop' branch.

Under the current model, there is only a single schema. Over and above the schema, additional validations (including validations against declarations in an OSCAL instance) will be supported via Schematron (and/or other means).

We haven't rewritten docs yet since it's still soft but we want something much simpler than the earlier concept.

[joshualubell]

So it sounds like I should wait until the schema stabilizes a little before trying to create OSCAL instances.

For what it's worth, you might want to take a look at the rnc and schematron I created for tailored 800-53 baselines. See https://github.com/usnistgov/sctools/blob/master/bt/examples/tailored.rnc and https://github.com/usnistgov/sctools/blob/master/bt/examples/tailored.sch

My schematron duplicates some of the constaints encoded in my Baseline Tailor XForms code.

I think a big challenge with OSCAL is to keep it sufficiently "simple" while allowing for all the different varieties of tailoring and for security control catalogs other than 800-53. My implementation considered only 800-53 and limited tailoring to supplemental guidance text and scoping in/out. I did not try to deal with parameters.

[wendellpiez]

Josh, that is fantastic I will definitely take a look at that.

I'd like to say it's stable enough to try but I keep thinking it is, then it isn't. To slake curiosity (and maybe ring early alarm bells if there are any) feel free to keep an eye on:

ISO 27002 mockup
SP800-53A controls with objectives

As of this afternoon there are three separate validations taking place: RNC (to be XSD in release); Schematron for "OSCAL consistency", then a different Schematron for validating OSCAL against its (own) declarations for properties and statements on controls.

There is still much to explain -- and write up.

[JJediny]

If I'd ever seen more beautiful .xsd before this, I have now rebaselined. In all seriousness,

• it is using standard min/max to detect minimal input validation
• it is incredibly clean use of tag/class
• key/value pairs seem strong

We really need to answer the .xsd to .json (schema) sync done in an automated fashion, with a command/run/commit workflow. I have been working with NOAA/FGDC on a similar need for metadata transformation. There is a clear need on many ends to have a partnership support for how to perform that transformation with integrity.

[wendellpiez]

Thanks for the kind words, even if the XSD syntax (as opposed to the modeling) is entirely not our doing :-) - we are currently producing the XSD by automated conversion from RNC source. Over time the maintenance may move away from RNC to RNG or XSD syntax, but this working for now.

How feasible are mappings to other forms of representation will depend largely (entirely?) on how simple the model is. However, keeping the basic tag set simple while retaining the flexibility we need, requires permitting complexity at another level. So far it's our working assumption that OSCAL can do what is necessary in its declarations model (balancing the need to constrain with the need for open-ended flexibility). What this means in practice is that a perfectly generic OSCAL-to-anything transformation may typically be very messy and sloppy, at least until "construed" (semantically reduced) at the other end -- at the same time, OSCAL would support very clean transformations or conversions in cases where the mapping can be tailored on both sides (that is, in the specific case that have resources or capabilities to do this, not the generic case "off the shelf").

[david-waltermire]

We have moved to a model-per-layer schema approach. This issue is OBE and will be closed as a result.