Revamp project to work with latest OSCAL #88

Some file locations changed in the latest OSCAL repo. Addressing: $ go generate 2019/12/16 14:03:57 open OSCAL/schema/metaschema/oscal-catalog-metaschema.xml: no such file or directory exit status 1 metaschema.go:9: running "go": exit status 1

When generating go out of xml schema errors are likely to occur. It is handy to see generated file along the errors as that's exactly what's needed for diagnosis.

Latest OSCAL content uses multiple imports.

and process them correctly.

It would be invalid.

Newest oscal repo contains references to field definitions instead of direct fields. For instance see: <field ref="description"/> <field ref="remarks" in-xml="WITH_WRAPPER"/> <field ref="party-id"/>

Some types may be defined using <field ref="x"/> element. In that case, we have to find relevant <define-field name="x"> element and fetch definition from there.

Assemblies no longer appear in the OSCAL metaschema

Newest oscal repo contains references to assembly definitions instead of direct assembly. For instance see: <assembly ref="metadata"/> <assembly ref="back-matter"/>

This will one day allow us to work well with multiple inherited metaschemas.

Some types may be defined using <assembly ref="x"/> element. In that case, we have to find relevant <define-assembly name="x"> element and fetch definition from there.

If some assembly is allowed to repeat we have to implement it as slice not as pointer. Example may be: <assembly ref="responsible-party" max-occurs="unbounded"> <group-as name="responsible-parties" in-json="BY_KEY"/> </assembly>

If some field is allowed to repeat we have to implement it as a slice not as a pointer. Example may be: <field ref="doc-id" max-occurs="unbounded"> <group-as name="document-ids"/> </field>

These are no longer used.

instead of list of define-flags. This will later allow us to clean-up a bit.

…nt definitions This will surely end-up less tedious than getting Def in template.

Previously, for some reason, this was not returning any comments on latest OSCAL

no longer needed

… way

To work well with multiple imports at the same time.

…a.xml

Learn how to handle special characters consistently, instead.

…a.xml

Previously, it was generated by different name.

This will not only allow us to have naming consistent, further it will make all slices to be named in plural form.

That way users do not need to remember where a particular item is defined and users do not need to import nominal_catalog package and validation_root package, hence these become internal implementation detail.

OSCAL standard went from Controls having Subcontrols to have recursive relationship between Controls and hence each Control may have child Controls.

Latest OSCAL metaschema does not contain <prose> element as first class citizen.

This is what they did in usnistgov/OSCAL repo as well. Also update the constraints to the latest list of as-types that appear in there.

as it may contain xhtml markup.

We will have to re-implement Prose manipulation later on. Project will be better served if we just remove the current implementation and re-implement once the project compiles with the latest oscal.

Even though it is just a string for now. We will later need to have struct built around the string.

in master OSCAL repo.

It feels we don't need to over complicate this. Also, refactor ValidateHref to proper public instance method.

…odify element

Not sure why these were added, but they certainly are no longer needed. Addressing: oscal generate catalogs --profile profile.xml

With growing number of formats/components, users will be surely confused at start. Let's provide them with info command.

It is not used.

It is no longer used.

OSCAL XML elements remain in singular form like <responsible-party .../> while on the other hand, JSON contains pluralized items, like responsible-parties: [ ... ],

Co-Authored-By: anweiss <2326106+anweiss@users.noreply.github.com>

With growing number of document types in OSCAL standard, we will need to recognize the document type more often than not.

to covert oscal file to human readable html

These files are already dated and none of them conform to the latest oscal.

This file is already dated and it does not conform to the latest oscal.

This will result in more quality output in cases like xmllint missing.

Firstly, with improved error handling, we will get nice error anyway (in case the file does not exist). Secondly, cli/cmd/validate already checks the file existence.

It is no longer needed, with the latest oscal json schema.

Although, getting the file format out file extension is rather lame, it is what other parts of the code so far do. I envision, we will have to rewrite the format heuristic with look ahead parser one day. However, at this early stage it is good enough.

…hema This will highly improve usability of the tool and thus increase chances that people will validate their own files. Further, validating file automatically shall turn out beneficial to the tool itself, once we start validating file oscalkit itself produces.

…schema

Even though it is not used in SSP and shall not be imported. It may be used by other metaschemas (like component) and thus we should reason about the need of importing it. As a side effect this re-shuffles some of the existing imports.

This is skeleton for converting opencontrols. It will be completed in following commits.

This completes the required metadata in oscal:ssp. Next step is to actually convert each control one by one.

for each open control on the input

This is especially useful when processing multiple files at once by `oscalkit validate`.

Co-Authored-By: anweiss <2326106+anweiss@users.noreply.github.com>

@anweiss

As @anweiss suggested. Thanks!

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Revamp project to work with latest OSCAL #88

Revamp project to work with latest OSCAL #88

Commits on Feb 4, 2020

Commits on Feb 5, 2020