@david-waltermire-nist, sorry, I cannot change it to draft back bc of perms/I am the author the PR. This is WIP until otherwise stated, can you help me change it back? :-)

OK, so I talked with Wendell through a potential bug in the supermodel -> converter generator -> running the OSCAL XML to JSON converter on some example files in here, specifically oscal_leveraging-example_ssp.xml. This is causing this error with examples file in the updated pipelines in this branch using more current develop OSCAL and in it develop metaschema submodule updates.

<nm:ERROR xmlns:err="http://www.w3.org/2005/xqt-errors" xmlns:nm="http://csrc.nist.gov/ns/metaschema" code="err:FOJS0006">xml-to-json: Child elements of &lt;map&gt; must have a key attribute</nm:ERROR>

It would seem this has something to do with how specifically this system-id without a type URI is handled with the current supermodel analysis in making the converters with the converter generator. I am having trouble piecing together where the model analysis occurs in the pipeline and the super model itself is generated, but I finally noticed the key difference I was not noticing on Friday.

The system-id in the generated supermodel:

      <group in-json="ARRAY" key="system-ids">
         <field collapsible="no" as-type="string" name="system-id" gi="system-id"><!-- NOTE: the field should have an in-json="SCALAR" attribute or something sensible, but it does not. -->
            <value as-type="string" key="id" in-json="string">saas_system_iaas_customer</value>
         </field>
      </group>

I will potentially convert this into a metaschema bug report when I am sure it is a bug and know more when discussing with Wendell on Monday or early next week.

Some other examples in the example document instance converted to the supermodel I hadn't noticed before. (Interesting and also of note: the field definition for system-id is the only one not in the SSP metaschema definition but imported through a module, maybe something worth tracking down?

                     <group in-json="ARRAY" key="information-type-ids">
                        <field collapsible="no" as-type="string" name="information-type-id"
                           gi="information-type-id" in-json="SCALAR">
                           <value as-type="string" in-json="string">C.3.5.8</value>
                        </field>
                     </group>

            <group in-json="ARRAY" key="role-ids">
               <field collapsible="no" as-type="token" name="role-id" gi="role-id" in-json="SCALAR">
                  <value as-type="token" in-json="string">admin</value>
               </field>
            </group>

                  <group in-json="ARRAY" key="functions-performed">
                     <field collapsible="no" as-type="string" name="function-performed"
                        gi="function-performed" in-json="SCALAR">
                        <value as-type="string" in-json="string">Manages the components within the
                           SaaS.</value>
                     </field>
                  </group>

                  <group in-json="ARRAY" key="values">
                     <field collapsible="no" as-type="string" name="parameter-value" gi="value"
                        in-json="SCALAR">
                        <value as-type="string" in-json="string">privileged and
                           non-privileged</value>
                     </field>
                  </group>

To move this along for now: I rebased this off of the current PR #144 for #116. Since that is a branch off my fork, I cannot really point that as the target of this PR. If the CI/CD fixes land, I can rebase again, examples will validate, and builds will work when this work is reviewed and merged as well.

This still needs rebasing after usnistgov/metaschema#240 and usnistgov/metaschema#241 are merged into usnistgov/OSCAL and the submodule can be updated to touch up CI/CD issues, but the example content is in a good place for the NIST team and OSCAL community to review the examples content on its merits separate of those issues.

@aj-stein-nist As we discussed today, this needs to be rebased to address the CI problems. Let me know when this is done and I can merge this PR.

This is blocked by #183 and any pending work that must be resolved and completed as marked by the resolution of #116. Moving to Sprint 65 tentatively.