If any 'unused' definition appears in a schema, we have a bug.
+If any 'unused' definition appears in a schema, we have a bug.
+Tested: 29 April 2021 at 09:08
-| - | passed: 2 | -pending: 0 | -failed: 0 | -total: 2 | -
|---|---|---|---|---|
| poc-on-remote-file | -1 | -0 | -0 | -1 | -
| poc-locally | -1 | -0 | -0 | -1 | -
| poc-on-remote-file | -passed: 1 / pending: 0 / failed: 0 / total: 1 | -
|---|---|
| An example of a pre-publication QA step | -passed: 1 / pending: 0 / failed: 0 / total: 1 | -
| The string does not start with 'oscal-', which we really want assert shortname-format-says-oscal - /m:METASCHEMA/m:short-name | -Success | -
| poc-locally | -passed: 1 / pending: 0 / failed: 0 / total: 1 | -
|---|---|
| An example of a pre-publication QA step | -passed: 1 / pending: 0 / failed: 0 / total: 1 | -
| The string does not start with 'oscal-', which we really want assert shortname-format-says-oscal | -Success | -
Tested: 28 April 2021 at 17:02
-| - | passed: 1 | -pending: 0 | -failed: 0 | -total: 1 | -
|---|---|---|---|---|
| poc-on-remote-file | -1 | -0 | -0 | -1 | -
| poc-on-remote-file | -passed: 1 / pending: 0 / failed: 0 / total: 1 | -
|---|---|
| Seeing any name clashes | -passed: 1 / pending: 0 / failed: 0 / total: 1 | -
| No name clash found not assert detect-xml-sibling-name-clash | -Success | -
The OSCAL Control Catalog format can be used to describe a collection of security controls and related control enhancements, along with contextualizing documentation and metadata. The root of the Control Catalog format is catalog.
Back matter including references and resources.
-Catalogs may use one or more group objects to subdivide the control contents of a catalog.
An OSCAL catalog model provides a structured representation of control information.
-A class can be used in validation rules to express extra constraints over named items of a specific class value.
A class can also be used in an OSCAL profile as a means to target an alteration to control content.
Catalogs can use a group to collect related controls into a single grouping. That can be useful to group controls into a family or other logical grouping.
A group may have its own properties, statements, parameters, and references, which are inherited by all members of that group.
A class can be used in validation rules to express extra constraints over named items of a specific class value.
A class can also be used in an OSCAL profile as a means to target an alteration to control content.
control. For example, a value of 'withdrawn' can indicate that the control has been withdrawn and should no longer be used.Controls may be grouped using group, and controls may be partitioned using part or further enhanced (extended) using control.
A control must have a part with the name "statement", which represents the textual narrative of the control. This "statement" part must occur only once, but may have nested parts to allow for multiple paragraphs or sections of text.
-Provides a means to segment the value space for the name, so that different organizations and individuals can assert control over the allowed names and associated text used in a part. This allows the semantics associated with a given name to be defined on an organization-by-organization basis.
An organization MUST use a URI that they have control over. e.g., a domain registered to the organization in a URI, a registered uniform resource names (URN) namespace.
-When a ns is not provided, its value should be assumed to be http://csrc.nist.gov/ns/oscal and the name should be a name defined by the associated OSCAL model.
name. This can be used to further distinguish or discriminate between the semantics of multiple parts of the same control with the same name and ns. A class can be used in validation rules to express extra constraints over named items of a specific class value.
A class can also be used in an OSCAL profile as a means to target an alteration to control content.
A part provides for logical partitioning of prose, and can be thought of as a grouping structure (e.g., section). A part can have child parts allowing for arbitrary nesting of prose content (e.g., statement hierarchy). A part can contain prop objects that allow for enriching prose text with structured name/value information.
A part can be assigned an optional id, which allows for internal and external references to the textual concept contained within a part. A id provides a means for an OSCAL profile, or a higher layer OSCAL model to reference a specific part within a catalog. For example, an id can be used to reference or to make modifications to a control statement in a profile.
Use of part and prop provides for a wide degree of extensibility within the OSCAL catalog model. The optional ns provides a means to qualify a part's name, allowing for organization-specific vocabularies to be defined with clear semantics. Any organization that extends OSCAL in this way should consistently assign a ns value that represents the organization, making a given namespace qualified name unique to that organization. This allows the combination of ns and name to always be unique and unambiguous, even when mixed with extensions from other organizations. Each organization is responsible for governance of their own extensions, and is strongly encouraged to publish their extensions as standards to their user community. If no ns is provided, the name is expected to be in the "OSCAL" namespace.
To ensure a ns is unique to an organization and naming conflicts are avoided, a URI containing a DNS or other globally defined organization name should be used. For example, if FedRAMP and DoD both extend OSCAL, FedRAMP will use the ns "https://fedramp.gov", while DoD will use the ns "https://defense.gov" for any organization specific name.
Tools that process OSCAL content are not required to interpret unrecognized OSCAL extensions; however, OSCAL compliant tools should not modify or remove unrecognized extensions, unless there is a compelling reason to do so, such as data sensitivity.
-A class can be used in validation rules to express extra constraints over named items of a specific class value.
value if no value is assigned.The label value should be suitable for inline display in a rendered catalog.
-A set of values provided in a catalog can be redefined at any higher layer of OSCAL (e.g., Profile).
-A set of parameter value choices, that may be picked from to set the parameter value.
-In a catalog, a parameter is typically used as a placeholder for the future assignment of a parameter value, although the OSCAL model allows for the direct assignment of a value if desired by the control author. The value may be optionally used to specify one or more values. If no value is provided, then it is expected that the value will be provided at the Profile or Implementation layer.
A parameter can include a variety of metadata options that support the future solicitation of one or more values. A label provides a textual placeholder that can be used in a tool to solicit parameter value input, or to display in catalog documentation. The desc provides a short description of what the parameter is used for, which can be used in tooling to help a user understand how to use the parameter. A constraint can be used to provide criteria for the allowed values. A guideline provides a recommendation for the use of a parameter.
A set of parameter value choices, that may be picked from to set the parameter value.
-id value.Since responsible-party associates multiple party-uuid entries with a single role-id, each role-id must be referenced only once.
While published, last-modified, oscal-version, and version are not required, values for these entries should be provided if the information is known. For a revision entry to be considered valid, at least one of the following items must be provided: published, last-modified, version, or a link with a rel of source
.
Typically, the physical address of the location will be used here. If this information is sensitive, then a mailing address can be used instead.
-This is a contact email associated with the location.
-A phone number used to contact the location.
-class can be used to indicate a subclass of data-center.location defined in metadata. location defined in metadata. This is a contact email associated with the party.
-A phone number used to contact the party.
-Parties of both the person or organization type can be associated with an organization using the member-of-organization.
party defined in metadata. OSCAL has defined a set of standardized roles for consistent use in OSCAL documents. This allows tools consuming OSCAL content to infer specific semantics when these roles are used. These roles are documented in the specific contexts of their use (e.g., responsible-party, responsible-role). When using such a role, it is necessary to define these roles in this list, which will then allow such a role to be referenced.
-Permissible values to be determined closer to the application (e.g. by a receiving authority).
-The text is used to define the endnote text, without any required bibliographic structure. If structured bibliographic data is needed, then the biblio can be used for this purpose.
A biblio can be used to capture a structured bibliographical citation in an appropriate format.
When appearing as part of a resource/rlink, the hash applies to the resource referenced by the href.
This construct is different from link, which makes no provision for a hash or formal title.
Multiple rlink can be included for a resource. In such a case, all provided rlink items are intended to be equivalent in content, but may differ in structure. A media-type is used to identify the format of a given rlink, and can be used to differentiate a items in a collection of rlinks. The media-type also provides a hint to the OSCAL document consumer about the structure of the resource referenced by the rlink.
resource. This is the name that will be assigned to the file when the file is decoded.Ensures that each rlink item references a unique resource.
-Ensures that all base64 resources have a unique filename.
A title is required when a citation is provided.
A resource can be used in two ways. 1) it may point to an specific retrievable network resource using a rlink, or 2) it may be included as an attachment using a base64. A resource may contain multiple rlink and base64 entries that represent alternative download locations (rlink) and attachments (base64) for the same resource. Both rlink and base64 allow for a media-type to be specified, which is used to distinguish between different representations of the same resource (e.g., Microsoft Word, PDF). When multiple rlink and base64 items are included for a given resource, all items must contain equivalent information. This allows the document consumer to choose a preferred item to process based on a the selected item's media-type. This is extremely important when the items represent OSCAL content that is represented in alternate formats (i.e., XML, JSON, YAML), allowing the same OSCAL data to be processed from any of the available formats indicated by the items.
When a resource includes a citation, then the title and citation properties must both be included.
Provides a collection of identified resource objects that can be referenced by a link with a rel value of "reference" and an href value that is a fragment "#" followed by a reference to a reference identifier. Other specialized link "rel" values also use this pattern when indicated in that context of use.
The following is a contrived example to show the use of link, citation, and resource.
-Provides a means to segment the value space for the name, so that different organizations and individuals can assert control over the allowed names and associated values used in a property. This allows the semantics associated with a given name/value pair to be defined on an organization-by-organization basis.
An organization MUST use a URI that they have control over. e.g., a domain registered to the organization in a URI, a registered uniform resource names (URN) namespace.
-When a ns is not provided, its value should be assumed to be http://csrc.nist.gov/ns/oscal and the name should be a name defined by the associated OSCAL model.
name. This can be used to further distinguish or discriminate between the semantics of multiple properties of the same object with the same name and ns. A class can be used in validation rules to express extra constraints over named items of a specific class value.
Properties permit the deployment and management of arbitrary controlled values, within OSCAL objects. A property can be included for any purpose useful to an application or implementation. Typically, properties will be used to sort, filter, select, order, and arrange OSCAL content objects, to relate OSCAL objects to one another, or to associate an OSCAL object to class hierarchies, taxonomies, or external authorities. Thus, the lexical composition of properties may be constrained by external processes to ensure consistency.
-Property allows for associated remarks that describe why the specific property value was applied to the containing object, or the significance of the value in the context of the containing object.
-The value of the href can be an internet resource, or a local reference using a fragment e.g. #fragment that points to a back-matter
- resource in the same document.
If a local reference using a fragment is used, this will be indicated by a fragment "#" followed by an identifier which references an identified resource in the document's back-matter or another object that is within the scope of the containing OSCAL document.
If an internet resource is used, the href value will be an absolute or relative URI pointing to the location of the referenced resource. A relative URI will be resolved relative to the location of the document containing the link.
The media-type provides a hint about the content model of the referenced resource. A valid entry from the IANA Media Types registry SHOULD be used.
To provide a cryptographic hash for a remote target resource, a local reference to a back matter resource is needed. The resource allows one or more hash values to be provided using the rlink/hash object.
The OSCAL link is a roughly based on the HTML link element.
The following is a contrived example to show the use of link, citation, and resource.
-Specifies one or more parties that are responsible for performing the associated role.
Any other value used MUST be a value defined in the W3C XML Security Algorithm Cross-Reference Digest Methods (W3C, April 2013) or RFC 6931 Section 2.1.5 New SHA Functions.
-A hash value can be used to authenticate that a referenced resource is the same resources as was pointed to by the author of the reference.
-This value represents the point in time when the OSCAL document was published. Typically, this date value will be machine generated at the time the containing document is published.
-In some cases, an OSCAL document may be derived from some source material in a different format. In such a case, the published value should indicate when the OSCAL document was published, not the source material. Where necessary, the publication date of the original source material can be captured as a named property or custom metadata construct.
A publisher of OSCAL content can use this data point along with its siblings last-modified and version to establish a sequence of successive revisions of a given OSCAL-based publication. The metadata for previous revisions can be represented as a revision in this object.
This value represents the point in time when the OSCAL document was last updated, or at the point of creation the creation date. Typically, this date value will be machine generated at time of creation or modification.
-In some cases, an OSCAL document may be derived from some source material in a different format. In such a case, the last-modified value should indicate the modification time of the OSCAL document, not the source material.
A publisher of OSCAL content can use this data point along with its siblings published and version to establish a sequence of successive revisions of a given OSCAL-based publication. The metadata for previous revisions can be represented as a revision in this object.
A version string may be a release number, sequence number, date, or other identifier suffcient to distinguish between different document versions. This version is typically set by the document owner or by the tool used to maintain the content.
-While not required, it is recommended that OSCAL content authors use Semantic Versioning as a format for version strings. This allows for the easy identification of a version tree consisting of major, minor, and patch numbers.
-A publisher of OSCAL content can use this data point along with its siblings published and last-modified to establish a sequence of successive revisions of a given OSCAL-based publication. The metadata for previous revisions can be represented as a revision in this object.
Indicates the version of the OSCAL model to which this data set conforms, for example 1.1.0
or 1.0.0-M1
. That can be used as a hint by a tool to indicate which version of the OSCAL XML or JSON schema to use for validation.
scheme. A document identifier provides a globally unique identifier for a group of documents that are to be treated as different versions of the same document. If this element does not appear, or if the value of this element is empty, the value of "document-id" is equal to the value of the "uuid" flag of the top-level root element.This element is optional, but it will always have a valid value, as if it is missing the value of "document-id" is assumed to be equal to the UUID of the root. This requirement allows for document creators to retroactively link an update to the original version, by providing a document-id on the new document that is equal to the uuid of the original document.
-Stylesheet: C:/Users/wap1/Documents/usnistgov/OSCAL/build/metaschema/toolchains/xslt-M4/compose/metaschema-collect.xsl
- -Tested: 26 April 2021 at 14:09
-| - | passed: 1 | -pending: 0 | -failed: 2 | -total: 3 | -
|---|---|---|---|---|
| Working metaschema | -1 | -0 | -0 | -1 | -
| Metaschema skeleton | -0 | -0 | -1 | -1 | -
| Nested locals | -0 | -0 | -1 | -1 | -
| Working metaschema | -passed: 1 / pending: 0 / failed: 0 / total: 1 | -
|---|---|
| Modules collected, no loops | -Success | -
| Metaschema skeleton | -passed: 0 / pending: 0 / failed: 1 / total: 1 | -
|---|---|
| Modules collected, no loops | -Failure | -
| Result | -Expected Result | -
|---|---|
|
- XPath <METASCHEMA xmlns="http://csrc.nist.gov/ns/oscal/metaschema/1.0" - xmlns:opr="http://csrc.nist.gov/ns/oscal/profile-resolution" - module="test" - src="file:/C:/Users/wap1/Documents/usnistgov/OSCAL/build/metaschema/toolchains/xslt-M4/compose/testing/1_collected/xspec/collect-compiled.xsl"> - <short-name>test</short-name> - <define-assembly scope="global" - name="root" - module="test" - key-name="test:root"> - <root-name>root-assembly</root-name> - <flag required="no" - ref="top-level-flag" /> - <define-flag required="no" - as-type="string" - name="local-flag"> - <formal-name>Locally defined flag</formal-name> - <description>XXX</description> - </define-flag> - <model> - <field max-occurs="unbounded" - min-occurs="0" - ref="top-level-global-field"> - <group-by name="top-level-global-field-sequence" /> - </field> - <field max-occurs="1" - min-occurs="0" - ref="top-level-local-field" /> - <define-field max-occurs="1" - min-occurs="0" - collapsible="no" - as-type="string" - name="local-field"> - <formal-name>Locally defined field</formal-name> - <description>XXX</description> - </define-field> - </model> - </define-assembly> - <define-field collapsible="no" - as-type="string" - scope="global" - name="top-level-global-field" - module="test" - key-name="test:top-level-global-field" /> - <define-field collapsible="no" - as-type="string" - scope="local" - name="top-level-local-field" - module="test" - key-name="test:top-level-local-field" /> - <define-flag as-type="string" - scope="global" - name="top-level-flag" - module="test" - key-name="test:top-level-flag" /> -</METASCHEMA>- |
-
- XPath <METASCHEMA xmlns="http://csrc.nist.gov/ns/oscal/metaschema/1.0" - xmlns:opr="http://csrc.nist.gov/ns/oscal/profile-resolution" - src="..." - module="test"> - <short-name>test</short-name> - <define-assembly name="root" - module="test" - key-name="test:root" - scope="global"> - <root-name>root-assembly</root-name> - <flag ref="top-level-flag" - required="no"> - <use-name>tlf</use-name> - </flag> - <define-flag name="local-flag" - as-type="string" - required="no"> - <formal-name>Locally defined flag</formal-name> - <description>XXX</description> - </define-flag> - <model> - <field ref="top-level-global-field" - min-occurs="0" - max-occurs="unbounded"> - <group-by name="top-level-global-field-sequence" /> - </field> - <field ref="top-level-local-field" - min-occurs="0" - max-occurs="1" /> - <define-field name="local-field" - as-type="string" - min-occurs="0" - max-occurs="1" - collapsible="no"> - <formal-name>Locally defined field</formal-name> - <description>XXX</description> - </define-field> - </model> - </define-assembly> - <define-field name="top-level-global-field" - module="test" - key-name="test:top-level-global-field" - scope="global" - as-type="string" - collapsible="no" /> - <define-field name="top-level-local-field" - scope="local" - module="test" - key-name="test:top-level-local-field" - as-type="string" - collapsible="no" /> - <define-flag name="top-level-flag" - module="test" - key-name="test:top-level-flag" - scope="global" - as-type="string" /> -</METASCHEMA>- |
-
| Nested locals | -passed: 0 / pending: 0 / failed: 1 / total: 1 | -
|---|---|
| Local definitions preserved with amended names | -Failure | -
| Result | -Expected Result | -
|---|---|
|
- XPath <METASCHEMA xmlns="http://csrc.nist.gov/ns/oscal/metaschema/1.0" - xmlns:opr="http://csrc.nist.gov/ns/oscal/profile-resolution" - module="test" - src="file:/C:/Users/wap1/Documents/usnistgov/OSCAL/build/metaschema/toolchains/xslt-M4/compose/testing/1_collected/xspec/collect-compiled.xsl"> - <short-name>test</short-name> - <define-assembly scope="global" - name="root" - module="test" - key-name="test:root"> - <root-name>root-assembly</root-name> - <flag required="no" - ref="top-level-flag"> - <use-name>tlf</use-name> - </flag> - <define-flag required="no" - as-type="string" - name="local-flag"> - <formal-name>Locally defined flag</formal-name> - <description>XXX</description> - </define-flag> - <model> - <field max-occurs="1" - min-occurs="0" - ref="top-level-global-field" /> - <field max-occurs="1" - min-occurs="0" - ref="top-level-local-field" /> - <assembly max-occurs="1" - min-occurs="0" - ref="top-level-local-assembly" /> - <define-field max-occurs="1" - min-occurs="0" - collapsible="no" - as-type="string" - name="local-field"> - <formal-name>Locally defined field</formal-name> - <description>XXX</description> - </define-field> - </model> - </define-assembly> - <define-field collapsible="no" - as-type="string" - scope="global" - name="top-level-global-field" - module="test" - key-name="test:top-level-global-field" /> - <define-field collapsible="no" - as-type="string" - scope="local" - name="top-level-local-field" - module="test" - key-name="test:top-level-local-field"> - <formal-name>Included twice</formal-name> - </define-field> - <define-assembly scope="local" - name="top-level-local-assembly" - module="test" - key-name="test:top-level-local-assembly"> - <model> - <field max-occurs="1" - min-occurs="0" - ref="top-level-local-field" /> - <assembly max-occurs="1" - min-occurs="0" - ref="top-level-local-assembly" /> - </model> - </define-assembly> - <define-flag as-type="string" - scope="global" - name="top-level-flag" - module="test" - key-name="test:top-level-flag" /> -</METASCHEMA>- |
-
- XPath <METASCHEMA xmlns="http://csrc.nist.gov/ns/oscal/metaschema/1.0" - xmlns:opr="http://csrc.nist.gov/ns/oscal/profile-resolution" - src="..." - module="test"> - <short-name>test</short-name> - <define-assembly name="root" - module="test" - key-name="test:root" - scope="global"> - <root-name>root-assembly</root-name> - <flag ref="top-level-flag" - required="no" /> - <define-flag name="local-flag" - as-type="string" - required="no"> - <formal-name>Locally defined flag</formal-name> - <description>XXX</description> - </define-flag> - <model> - <field ref="top-level-global-field" - min-occurs="0" - max-occurs="1" /> - <field ref="top-level-local-field" - min-occurs="0" - max-occurs="1" /> - <assembly ref="top-level-local-assembly" - min-occurs="0" - max-occurs="1" /> - <define-field name="local-field" - as-type="string" - min-occurs="0" - max-occurs="1" - collapsible="no"> - <formal-name>Locally defined field</formal-name> - <description>XXX</description> - </define-field> - </model> - </define-assembly> - <define-field name="top-level-global-field" - module="test" - key-name="test:top-level-global-field" - scope="global" - as-type="string" - collapsible="no" /> - <define-field name="top-level-local-field" - scope="local" - module="test" - key-name="test:top-level-local-field" - as-type="string" - collapsible="no"> - <formal-name>Included twice</formal-name> - </define-field> - <define-assembly name="top-level-local-assembly" - scope="local" - module="test" - key-name="test:top-level-local-assembly"> - <model> - <field ref="top-level-local-field" - min-occurs="0" - max-occurs="1" /> - <assembly ref="top-level-local-assembly" - min-occurs="0" - max-occurs="1" /> - </model> - </define-assembly> - <define-flag name="top-level-flag" - module="test" - key-name="test:top-level-flag" - scope="global" - as-type="string" /> -</METASCHEMA>- |
-
For exercising Metaschema semantics with respect to modular assembly and composition.
Stylesheet: C:/Users/wap1/Documents/usnistgov/OSCAL/build/metaschema/toolchains/xslt-M4/compose/metaschema-reduce1.xsl
- -Tested: 16 October 2020 at 12:56
-| - | passed: 2 | -pending: 0 | -failed: 0 | -total: 2 | -
|---|---|---|---|---|
| Working metaschema | -1 | -0 | -0 | -1 | -
| Drop an extra | -1 | -0 | -0 | -1 | -
| Working metaschema | -passed: 1 / pending: 0 / failed: 0 / total: 1 | -
|---|---|
| Last definition is kept | -Success | -
| Drop an extra | -passed: 1 / pending: 0 / failed: 0 / total: 1 | -
|---|---|
| Only the second 'top-level-global-field' is kept | -Success | -
For exercising Metaschema semantics with respect to modular assembly and composition.
-Stylesheet: C:/Users/wap1/Documents/usnistgov/OSCAL/build/metaschema/toolchains/xslt-M4/compose/metaschema-digest.xsl
- -Tested: 15 October 2020 at 16:41
-| - | passed: 1 | -pending: 0 | -failed: 0 | -total: 1 | -
|---|---|---|---|---|
| Modular Assembly | -1 | -0 | -0 | -1 | -
| Modular Assembly | -passed: 1 / pending: 0 / failed: 0 / total: 1 | -
|---|---|
| Basic metaschema composition | -Success | -
For exercising Metaschema semantics with respect to modular assembly and composition.