diff --git a/docs/content/concepts/processing/profile-resolution.html b/docs/content/concepts/processing/profile-resolution.html index f75aef527a..324530c213 100644 --- a/docs/content/concepts/processing/profile-resolution.html +++ b/docs/content/concepts/processing/profile-resolution.html @@ -1,18 +1,18 @@ --- -title: OSCAL Profile Resolution -description: Transforming a profile into the tailored catalog it represents +title: OSCAL Profile Resolution Specification Draft +description: Working draft of the profile resolution specification. toc: enabled: true headingselectors: "h1, h2, h3, h4, h5" --- -
Please note that this specification is currently a work in progress and is subject to change. If you have any feedback or comments, please create an issue at the NIST OSCAL Github Repository: github.com/usnistgov/OSCAL.
This specification provides the minimal requirements for processing an OSCAL Profile to create a new OSCAL Catalog Document. This process of applying a profile to a catalog to create a new catalog is called +
Please note that this specification is currently a work in progress and is subject to change. If you have any feedback or comments, please create an issue at the NIST OSCAL Github Repository: github.com/usnistgov/OSCAL.
This specification provides the minimal requirements for processing an OSCAL Profile to create a new OSCAL Catalog Document. This process of applying a profile to a catalog to create a new catalog is called Profile Resolution. Not all OSCAL Profiles will be resolved, nor are expected to be; however, the resolution requirements in this document are crucial to understanding the intended functionality of any given OSCAL Profile. This specification is intended for software developers who intend to develop an OSCAL Profile Resolver, or for OSCAL Profile authors who want a more in-depth understanding of profile resolution. -
This document defines the normative requirements for an OSCAL Profile Resolver. Profile resolution is core to addressing a fundamental OSCAL requirement: - the representation of baselines separately from the control catalogs on which they depend). The requirements for resolution must therefore be well-defined and deterministic, - enabling tool developers and parties exchanging OSCAL Profiles can work from a common understanding.
No requirements are placed on implementation-level details, instead, requirements are laid out as what the output of resolution must look like given a certain input. +
+ Information systems are implemented against a baseline of security controls. An OSCAL Profile defines the selection and potential alterations to a control catalog that are needed to establish a baseline. However, the OSCAL implementation layer depends on having an OSCAL Catalog that represents the baseline of controls to be implemented. Profile Resolution allows for computing an effective catalog based on an OSCAL Profile. For a given OSCAL Profile, the Profile Resolution process needs to result in the same OSCAL Catalog when executed by different tools on different endpoints. The requirements for resolution must therefore be well-defined and deterministic, enabling tool developers and parties exchanging OSCAL Profiles to work from a common understanding. This document defines the normative requirements for an OSCAL Profile Resolver. +
No requirements are placed on implementation-level details, instead, requirements are laid out as what the output of resolution must look like given a certain input. By adhering to these requirements OSCAL producers, OSCAL consumers, and any other members of the OSCAL ecosystem can create and resolve profiles deterministically, - with repeatable results, regardless of the tool used.
Many core OSCAL concepts are defined on the OSCAL Terminology Page. The most important are repeated in this document, but readers should verify their understanding of all core OSCAL terms before reading this document.
Additionally, many terms in the wider domain have overloaded definitions. Unless defined otherwise by OSCAL or explicitly in this document, terms are to be understood as defined in the NIST CSRC Glossary.
+ with repeatable results, regardless of the tool used.
Many core OSCAL concepts are defined on the OSCAL Terminology Page. The most important are repeated in this document, but readers should verify their understanding of all core OSCAL terms before reading this document.
Additionally, many terms in the wider domain have overloaded definitions. Unless defined otherwise by OSCAL or explicitly in this document, terms are to be understood as defined in the NIST CSRC Glossary.
profile- an OSCAL Profile Document. Defines a set of inclusions, modifications, and transformations against a catalog. See OSCAL Profile Model. @@ -43,17 +43,17 @@
canonical order- the order of objects as required in the appropriate OSCAL Model (Profile, Catalog, etc.). This can differ from the above order when converting between "ordered" formats (ex. XML), and "non-ordered" formats (ex. JSON). -
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in +
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174]when, and only when, they appear in all capitals, as shown here. -
OSCAL supports a variety of serialization formats, each of which having it's own benefits and drawbacks. In this document, YAML (YAML Ain't Markup Language) is used to represent the various objects of the +
OSCAL supports a variety of serialization formats, each of which having it's own benefits and drawbacks. In this document, YAML (YAML Ain't Markup Language) is used to represent the various objects of the sourceand target. All examples and in-line references will be represented using YAML 1.2.
YAML maps cleanly to JSON, thus allowing easy use of existing JSON/XML transformers where needed. With that in mind, the OSCAL Complete JSON Referenceis a valuable resource for understanding the YAML-based information structures used in this document. All JSON properties and objects defined in the reference equate to a YAML mapping, list, or dictionary. -
YAML is a particularly human-readable format. For those unfamiliar with the format, the basics:
Each line is a key-value pair, presented as +
YAML is a particularly human-readable format. For those unfamiliar with the format, the basics:
Each line is a key-value pair, presented as
key:value
, or as
key:
with any number of list items on the following lines.
Indentation, spacing, and white space matters. Items below a key and indented one level in are members (or children) of that key.
List items are represented with a preceding dash @@ -68,14 +68,14 @@
#
) will be used to explain the elision.
Finally, although examples are syntactically faithful to OSCAL, they are not necessarily always formally valid in every respect. For example, OSCAL defines allowed property names (
props
) and values, and those rules may not be observed here. Examples are given for purposes of illustrating profile resolution semantics only, and should not be taken as normative for any actual use.
-
The specification is broken into the following major sections:
+
The specification is broken into the following major sections:
Phases of Profile Resolution- Lays out the necessary steps and phases of profile resolution. As each phase executes, the processor is understood to be creating and editing an intermediate representation of the output. There is one section for each of the three main phases.
Target Catalog Structure- Provides the requirements for structuring the final output from the intermediate representation generated throughout the previous section.
Please note: As referenced in the Purpose section - [See: Purpose], this specification makes no hard requirements on the specifics of implementation. It is feasible for an implementation to use no intermediate representation, and to directly and iteratively build the output. As long as all processing and output requirements are satisfied, any approach is allowed. With that said, the specification has been laid out to aid in implementation by providing a clear organization as a sequence of distinct operations. -
The overall intent of this document, in addition to defining strict requirements, is to provide rough guidelines on implementing an OSCAL Profile Resolution Tool. To this end, each phase of resolution will be framed as a series of transformations applied to an internal data structure that is persistent throughout the process. We call this "the intermediate".
Any examples that are labelled as "Intermediate" are pseudo-code, designed to represent how this data structure might look as we apply different operations to it. The example intermediates are often not valid OSCAL, and are not to be taken as guidance, but rather a useful visualization tool for implementers.
The authors believe that applying the steps of resolution in order against this intermediate representation is the simplest way to achieve full compliance with the specification. However, there is no requirement to implement profile resolution in this way. Requirements are given as rules on the output of resolution, and as such, tools can operate any way they would like internally.
An OSCAL Profile has three major sections, each which correspond to a phase of profile resolution. In order to complete the profile resolution process, each section must be fully parsed and a catalog output created.
It is strongly RECOMMENDED that implementations execute the following steps in the order that they are provided here (import, merge, modify). While it is possible to achieve compliance with a non-standard approach, the iterative nature of profile resolution lends itself to linear processing.
The three steps are + [See: Purpose], this specification makes no hard requirements on the specifics of implementation. It is feasible for an implementation to use no intermediate representation, and to directly and iteratively build the output. As long as all processing and output requirements are satisfied, any approach is allowed. With that said, the specification has been laid out to aid in implementation by providing a clear organization as a sequence of distinct operations. +
The overall intent of this document, in addition to defining strict requirements, is to provide rough guidelines on implementing an OSCAL Profile Resolution Tool. To this end, each phase of resolution will be framed as a series of transformations applied to an internal data structure that is persistent throughout the process. We call this "the intermediate".
Any examples that are labelled as "Intermediate" are pseudo-code, designed to represent how this data structure might look as we apply different operations to it. The example intermediates are often not valid OSCAL, and are not to be taken as guidance, but rather a useful visualization tool for implementers.
The authors believe that applying the steps of resolution in order against this intermediate representation is the simplest way to achieve full compliance with the specification. However, there is no requirement to implement profile resolution in this way. Requirements are given as rules on the output of resolution, and as such, tools can operate any way they would like internally.
An OSCAL Profile has three major sections, each which correspond to a phase of profile resolution. In order to complete the profile resolution process, each section must be fully parsed and a catalog output created.
It is strongly RECOMMENDED that implementations execute the following steps in the order that they are provided here (import, merge, modify). While it is possible to achieve compliance with a non-standard approach, the iterative nature of profile resolution lends itself to linear processing.
The three steps are import; merge; and modify. In brief: @@ -89,7 +89,7 @@
modify
directive in source profiles. If a
modify
directive is not provided, no changes will be made to the controls that have been imported/merged.
- As described in the previous section, when resolved, an OSCAL Profile takes the form of an OSCAL Catalog. The phases described below will produce outputs conforming to the catalog model.
A profile begins by listing a set of catalogs and/or profiles to be imported. Each is represented by a resolvable resource URI and a directive specifying which controls to import from that resource. These resources may be available as static resources, or they may be produced dynamically on request; such as is the case when a profile is imported. Imports are given in sequence after the metadata:
{{< highlight xml>}} +As described in the previous section, when resolved, an OSCAL Profile takes the form of an OSCAL Catalog. The phases described below will produce outputs conforming to the catalog model.
A profile begins by listing a set of catalogs and/or profiles to be imported. Each is represented by a resolvable resource URI and a directive specifying which controls to import from that resource. These resources may be available as static resources, or they may be produced dynamically on request; such as is the case when a profile is imported. Imports are given in sequence after the metadata:
{{< highlight xml>}} profile: uuid: ~ @@ -114,7 +114,7 @@While an internal reference appears as below (see - [See: Internal References]): + [See: Internal References]):
{{< highlight xml>}} profile: @@ -128,19 +128,20 @@All import directives will contain either
include-all: ~
or
include-controls
. These directives indicate which controls from the imported document are explicitly selected
- [See: Including Controls].
+ [See: Including Controls].
The following section contains requirements for processing the
import
child of a source
profile
-
Tools MUST resolve URIs by following +
Tools MUST resolve URIs by following Section 5 of RFC3986, with the exception of URI Fragments (URIs that start with "#"). URI Fragments MUST instead be resolved as defined in - [See: Internal References]. -
Tools MUST acquire resources at the resolved URI by following + [See: Internal References]. +
Tools MUST acquire resources at the resolved URI by following Section 5 of RFC3986, with the exception of URI Fragments (URIs that start with "#"). URI Fragments MUST instead be acquired as defined in - [See: Internal References]. -
For the purposes of resolving URIs using the above specification, the Base URI MUST be considered to be the absolute URI of the containing profile.
In the case that acquiring a resource fails, the tool MUST cease processing and provide an error. In order to ensure profile resolution results in the same catalog regardless of which tool resolves it, all imports must successfully resolve. While this may cause inconvenience if resources are frequently not available, it ensures interoperability.
Note that receiving a cached version of an import, or resolving an import that is otherwise unavailable through some other (but automatic) means still satisfies the above requirement. This specification does not put requirements on the precise function of the import, as long as the correct document is retrieved.
URI Fragments in OSCAL represent internal references to other OSCAL objects in the same document. These references follow the pattern of #{{objectID}}
. For example, the URI Fragment #param1
is referencing the Parameter with unique ID param1
.
In the context of the Import Phase, internal references will only appear as a reference to a profile or catalog that is in the resources
section of the source. When tools encounter such a reference, they MUST locate the object in resources
with the matching ID value, and resolve the import using the
- rlink
URI and the above resolution requirements.
-
If the object fetched cannot be found or is not a valid OSCAL object, the tool MUST cease processing and provide an error.
{{< highlight xml>}} + [See: Internal References]. +For the purposes of resolving URIs using the above specification, the Base URI MUST be considered to be the absolute URI of the containing profile.
In the case that acquiring a resource fails, the tool MUST cease processing and provide an error. In order to ensure profile resolution results in the same catalog regardless of which tool resolves it, all imports must successfully resolve. While this may cause inconvenience if resources are frequently not available, it ensures interoperability.
Note that receiving a cached version of an import, or resolving an import that is otherwise unavailable through some other (but automatic) means still satisfies the above requirement. This specification does not put requirements on the precise function of the import, as long as the correct document is retrieved.
URI Fragments in OSCAL represent internal references to other OSCAL objects in the same document. These references follow the pattern of #{{objectID}}
. For example, the URI Fragment #param1
is referencing the Parameter with unique ID param1
.
In the context of the Import Phase, internal references will only appear as a reference to a profile or catalog that is in the resources
section of the source. When tools encounter such a reference, they MUST locate the object in resources
with the matching UUID value, and resolve the resource.
+ By OSCAL model requirements, a given resource
can have zero to many rlink
objects and zero to one base64
objects; however, it must have at least one of the two present. Tools can assume that any of these each resolves to the same underlying OSCAL object, although potentially in different serialization formats.
+ For deterministic resolution of these backmatter OSCAL objects, tools need to adhere to the following requirements:
+
Tools MAY use any of the rlink
or base64
objects present in the resource
.
Tools MAY verify that each above objects resolves to the same underlying OSCAL object. If there are OSCAL Model content differences between the resolved objects, the tool SHOULD provide a warning.
When a rlink
is encountered and is to be resolved, it MUST be resolved by using a HTTP request to retrieve a byte stream.
When a base64
is encountered and is to be resolved, it MUST be considered a Byte Stream.
Regardless of its source, the Byte Stream MUST be decoded based on the algorithm defined in Section 4 RFC 4648.
If the object fetched cannot be found, or does not parse as an OSCAL catalog or profile, the tool MUST cease processing and provide an error.
{{< highlight xml>}} profile: metadata: ~ @@ -159,7 +160,7 @@If the resource acquired is an OSCAL Profile, the tool MUST apply this specification to resolve it, then continue processing having imported the resulting catalog.
When a profile imports a profile, the subordinate profile SHOULD be resolved first into a catalog using this specification, before it is imported. This presents the possibility of circular imports, when a profile is directed to import itself either directly or indirectly.
A + {{}}
If the resource acquired is an OSCAL Profile, the tool MUST apply this specification to resolve it, then continue processing having imported the resulting catalog.
When a profile imports a profile, the subordinate profile SHOULD be resolved first into a catalog using this specification, before it is imported. This presents the possibility of circular imports, when a profile is directed to import itself either directly or indirectly.
A circular import occurs when a profile imports an already imported profile, which was called at an earlier place in the import hierarchy. For example, if profile A imports profile B, and profile B imports profile A, the second import is circular. (An import at the top can only be circular if a profile tries to import itself.) If A imports B, B imports C and C imports A, C’s import is circular.
Note that an import can only be circular within the context of processing a particular profile. In the last example, C’s import would not be circular if invoked in the context of resolving B by itself.
If a processor encounters a circular import as described above (self-imports are inherently circular), the processor MUST cease processing and generate an error. @@ -190,7 +191,7 @@
Each import directive is processed to produce a set of controls. Note that this occurs even if the same catalog is imported multiple times: each distinct import collects controls into a separate + {{}}
Each import directive is processed to produce a set of controls. Note that this occurs even if the same catalog is imported multiple times: each distinct import collects controls into a separate selection:
{{< highlight xml>}} @@ -221,9 +222,9 @@The control inclusions are combined and collapsed in the next phase of processing, - merge(see [See: Merge Phase]) . -
Multiple imports against the same resource are allowed, and would most commonly occur when the profile author is using [See: Mapping Controls] to create very specific output. - Multiple imports may result in outputs with clashing control IDs if mapping or the merge directive is not set correctly.
The optional + merge(see [See: Merge Phase]) . +
Multiple imports against the same resource are allowed, and would most commonly occur when the profile author is using [See: Mapping Controls] to create very specific output. + Multiple imports may result in outputs with clashing control IDs if mapping or the merge directive is not set correctly.
The optional
mapping
child of a given
import
provides a simple ID remapping for objects included from that specific import. This provides the means for profile authors to proactively avoid clashing IDs of controls and other objects.
The Mapping section consists of 5 optional subsections, each covering a particular type of object. Each subsection is a list of ID mappings to be applied for objects that are the parent object type.
When encountering a given mapping instruction, processors:
MUST change the distinctive ID of that object to be equal to the value of the @@ -265,11 +266,11 @@
Each import contains directives on which controls from the imported catalog are to be fetched and used for further processing. Throughout the rest of the document we will refer to this as "inclusion". + {{}}
Each import contains directives on which controls from the imported catalog are to be fetched and used for further processing. Throughout the rest of the document we will refer to this as "inclusion". If a control is included, and the source profile makes no other changes to it, it will be present in the output. Exclusion directives in this section, as well as directives in the following two major sections (merge and modify), - may make changes to an included control or group that could cause it to appear differently, or not at all, in the output. Using the intermediate implementation approach, any control(s) that are included would be extracted from the referenced catalogs, any applicable mappings would be applied, then the controls(s) would be stored.
When an import provides the + may make changes to an included control or group that could cause it to appear differently, or not at all, in the output. Using the intermediate implementation approach, any control(s) that are included would be extracted from the referenced catalogs, any applicable mappings would be applied, then the controls(s) would be stored.
When an import provides the
include-all
directive, ALL controls and groups in the referenced document (including nested controls) MUST be included.
-
When an import provides the +
{{< highlight xml>}}include-all: ~{{}}When an import provides the
include-controls
directive, with a
with-id
child, all controls in the referenced document whose
id
match one of the listed
@@ -280,7 +281,7 @@
Controls may also be included using match patterns against their IDs. This is useful because related controls (either in a hierarchy, or together in a group) frequently have related IDs as well.
When an import provides the + {{}}
Controls may also be included using match patterns against their IDs. This is useful because related controls (either in a hierarchy, or together in a group) frequently have related IDs as well.
When an import provides the
include-controls
directive, with a
matching
child, all controls in the referenced document whose
id
matches one of the listed
@@ -293,9 +294,9 @@
In OSCAL, controls may contain child controls. For instance, in SP 800-53 many controls are supplemented with control enhancements; in OSCAL these are represented as child controls within parent controls. So parent AC-2 (in a given catalog) has children AC-2(1) through AC-2(13), for example.
By default, inclusion of a control also causes any of that control's ancestors (or parents) to also be included. By default, inclusion of a control DOES NOT cause the inclusion of any descendants (or children) of that control to be included. This applies to both controls and groups.
This default behavior can be modified by the following two optional children of the + {{}}
In OSCAL, controls may contain child controls. For instance, in SP 800-53 many controls are supplemented with control enhancements; in OSCAL these are represented as child controls within parent controls. So parent AC-2 (in a given catalog) has children AC-2(1) through AC-2(13), for example.
By default, inclusion of a control also causes any of that control's ancestors (or parents) to also be included. By default, inclusion of a control DOES NOT cause the inclusion of any descendants (or children) of that control to be included. This applies to both controls and groups.
This default behavior can be modified by the following two optional children of the
include-controls
object.
-
Child controls are, for the most part, treated the same as top level controls: they can be explicitly included using the selection directives above. As a shortcut to manually including all of the desired descendant controls of a given control, OSCAL provides the with-child-controls
option. with-child-controls
appears as a child object under a given inclusion directive, and defines additional behavior that is to be executed alongside the parent inclusion.
A +
When a control is selected, any child controls can be included by means the with-child-controls
flag. This provides an alternative to selecting child or descendant controls explicitly by id
or match. with-child-controls
appears as a child object under a given inclusion directive and defines behaviors listed below.
A
with-child-controls: yes
directive on an
include-controls
indicates that
all descendant controls of the included control MUST also be included.
@@ -305,11 +306,7 @@
If no
with-child-controls
is provided, the processor MUST consider the directive as being equivalent to one having
with-child-controls:no
.
-
Although similar to the above
- with-child-controls
, the optional
- with-parent-controls
applies to parents of the included control, and has the opposite default behavior. In order to maintain the structure of the source catalog, profile resolution includes all parents of an included control by default. If a profile author wants to change this structure, they should use an exclude directive that lists all of the undesired parents. As a shortcut for this,
- with-parent-controls
provides the following functionality:
-
A +
The the optional with-parent-controls
flag defines behavior applicable to parents or ancestors (a parent's parent etc.) of the included control, in cases of nested controls. with-parent-controls
appears as a child object under a given inclusion directive and defines the behaviors listed below. Its semantics assume that nesting of controls indicates logical dependencies in catalogs, which should be retained unless a profile specifically indicates otherwise.
A
with-parent-controls: yes
directive on an
include-controls
indicates that
all parent controls of the included control MUST also be included.
@@ -319,43 +316,43 @@
If no
with-parent-controls
is provided, the processor MUST consider the directive as being equivalent to one having
with-parent-controls:yes
.
-
Exclusions work the same way as inclusions, except with the opposite effect - the indicated control(s) do not appear in the target catalog.
Any control designated to be both included and excluded, MUST be excluded. This holds irrespective of the specificity of the selection for inclusion or exclusion. For example, if AC-1 is included by id +
Exclusions work the same way as inclusions, except with the opposite effect - the indicated control(s) do not appear in the target catalog.
Any control designated to be both included and excluded, MUST be excluded. This holds irrespective of the specificity of the selection for inclusion or exclusion. For example, if AC-1 is included by id
ac-1
and excluded by matching
ac.*
, it is excluded.
When
exclude-controls
has at least one
with-ids
or
matching
directive, the processor MUST follow the same rules as defined in the relevant sections above for these directives, but exclude instead of include any controls. All optional features (with-child-controls
, etc.) also apply to exclusion directives.
-
A given +
A given
import
may have any number of inclusion statements and any number of exclusion statements. Their effect is cumulative; any control that is included (or excluded) more than once MUST be considered to be included (or excluded) only once. In other words, a given control being included or excluded more than once has no effect. Exclusion still takes priority over inclusion (see above).
Note that this requirement only applies to controls included within the context of a single import. Controls with duplicate IDs included under a different
import
are not discarded. Also note that this redundancy pruning happens after any relevant mappings have been applied.
-
Any +
Any
param
that is not directly under a control is referred to as a
loose
param.
All loose params from both imported documents and the profile source MUST be included. These params will be kept in the final output if the document contains any references to them, and discarded otherwise. See
- [See: Pruning and Ordering]. Since new references can be created during the
+ [See: Pruning and Ordering]. Since new references can be created during the
modify
phase, tools should be careful not to prune params without fully understanding the final state of the output document.
-
Some source catalogs use +
Some source catalogs use
group
objects to place controls into arbitrary groupings. Tools will need to be aware of these groups when executing the "merge" phase below, as they will duplicated into the output under the "as-is" mode and can be referenced in "custom" mode. The naïve intermediate approach would keep all groups until all other phases are complete, but implementations may find it more performant to look ahead and prune unused groups early.
-
In order to ensure that implementers have as much flexibility as possible, requirements in this section have purposefully been kept minimal. Below are some common issues for implementers to be aware of:
The ordering and hierarchical organization of included controls as they were present in the original catalog may be used later in the resolution process. +
Group objects that have a child prop
object with name:keep and value:always MUST NOT be pruned (see [See: Pruning and Ordering]. Additional details on handling the final outputting of these groups can be found in the "merge" phase below.
In order to ensure that implementers have as much flexibility as possible, requirements in this section have purposefully been kept minimal. Below are some common issues for implementers to be aware of:
The ordering and hierarchical organization of included controls as they were present in the original catalog may be used later in the resolution process.
Specifically, if the profile is using the "as-is" structuring directive, the ordering and organziation of the output should match the source catalog as closely as possible.
- Implementations may want to track this information, or look ahead to see what structuring mode is being used. Note that "as-is" also requires implementations to replicate any use of the group
element.
At this point all requirements for content importing and control inclusion have been covered. If using the intermediate approach, the processor should have an intermediate that contains: a set of included controls and all of their child informational (non-control, non-group) objects, any relevant
+ Implementations may want to track this information, or look ahead to see what structuring mode is being used. Note that "as-is" also requires implementations to replicate any use of the group
element.
At this point all requirements for content importing and control inclusion have been covered. If using the intermediate approach, the processor should have an intermediate that contains: a set of included controls and all of their child informational (non-control, non-group) objects, any relevant
group
objects and their informational content, and a set of included "loose params"
- [See: Handling Params] (zero to many). The general structure of the intermediate would match that of the imported catalogs (i.e. nested controls remain nested, grouped controls remain grouped).
-
Profiles may contain a + [See: Handling Params] (zero to many). The general structure of the intermediate would match that of the imported catalogs (i.e. nested controls remain nested, grouped controls remain grouped). +
Profiles may contain a
merge
section, where directives are given to instruct the processor how to combine the set of included objects collected during the Import Phase.
merge
has two parts: a "combine" directive, and a "structuring" directive.
It is RECOMMENDED that tools apply the "combine" directive to the intermediate generated by the Import phase first, then apply the "structuring" directive.
The following section contains requirements for processing the
merge
child of a source profile.
-
+
combine
is an optional child of
merge
that provides the rules for dealing with objects that have duplicate (or clashing) distinct IDs
- [See: Distinct ID of Objects].
+ [See: Distinct ID of Objects].
There are two valid combination methods provided by OSCAL, provided by the
method
child of
combine
:
-
use-first: Use the first definition - the first control with a given ID is used; subsequent ones are discarded
keep: Keep - controls with the same ID are kept, retaining the clash
Note that "merge: combine" is deprecated, and MUST be considered undefined behavior when encountered.
In order to apply the combination method, IDs of each control explicitly included are compared against one another. As IDs are unique across entire OSCAL documents, different imports or any groupings have no bearing on collision. Processing requirements for each method are described below.
If no +
use-first: Use the first definition - the first control with a given ID is used; subsequent ones are discarded
keep: Keep - controls with the same ID are kept, retaining the clash
Note that "merge: combine" is deprecated, and MUST be considered undefined behavior when encountered.
In order to apply the combination method, IDs of each control explicitly included are compared against one another. As IDs are unique across entire OSCAL documents, different imports or any groupings have no bearing on collision. Processing requirements for each method are described below.
If no
merge
directive is given in the profile, or if a
merge
is given without a
combine
, merge conflicts MUST be treated as if
@@ -377,18 +374,18 @@
method:keep
When a merge is indicated by
method:keep
, or when no merge directive is given, the
keep
combination rule is used. Any control with the same distinctive ID
- [See: Distinct ID of Objects]MUST NOT not merged. (They are kept.)
+ [See: Distinct ID of Objects]MUST NOT not merged. (They are kept.)
Under this directive, colliding controls will result in invalid results, as they will both appear in the results with the same ID. Accordingly, this setting may be useful in ensuring integrity of references to controls as given in the profile: if any included control is called only once, clashing controls will not be produced and validation will succeed.
{{< highlight xml>}} + {{}}Under this directive, colliding controls will result in invalid results, as they will both appear in the results with the same ID. Accordingly, this setting may be useful in ensuring integrity of references to controls as given in the profile: if any included control is called only once, clashing controls will not be produced, disambiguating the result and avoiding validation errors.
{{< highlight xml>}} profile: imports: @@ -417,7 +414,7 @@In this case, downstream errors should be expected: the two
ac-1
controls clash with each other, as do the two
ac-2
controls.
-
Processors SHOULD provide a warning under the merge:keep directive when duplicate controls are detected. The processor MAY throw an error and cease processing (short-circuiting a certain future error) when duplicate controls are detected under the merge:keep directive.
Processors SHOULD provide a warning under the merge:keep directive when duplicate controls are detected. The processor MAY throw an error and cease processing (short-circuiting a certain future error) when duplicate controls are detected under the merge:keep directive.
method:use-first
method:merge
- Deprecated, unspecified behavior.
This section describes how a profile may dictate the structure of the target +
Deprecated, unspecified behavior.
This section describes how a profile may dictate the structure of the target
catalog
, apart from its
metadata
or
back-matter
. Optionally, one of three "structuring" directives can be included as a child of
@@ -462,7 +459,7 @@
flat
,
as-is
and
custom
. When one of these appears, it is the selected structuring directive. If more than one appears, processors MUST generate an error and cease processing. Processing requirements for each are given below:
- If no +
If no
merge
directive is given in the profile, or if a
merge
is given without a structuring directive, structuring the output MUST be treated as if the structuring directive
flat
was given. For example, a profile with no
@@ -483,7 +480,7 @@
Profiles with the "flat" merge directive MUST be resolved as unstructured catalogs, with no grouping or nesting of controls.
Unstructured catalog output MUST be produced by adhering to the following requirements:
All included controls are output to the target as a flat list directly under "catalog".
Any included "loose params" are output to the target as a flat list directly under "catalog".
Any groups are discarded.
An example of flat structuring is provided below
{{< highlight xml>}} + {{}}Profiles with the "flat" merge directive MUST be resolved as unstructured catalogs, with no grouping or nesting of controls.
Unstructured catalog output MUST be produced by adhering to the following requirements:
All included controls are output to the target as a flat list directly under "catalog".
Any included "loose params" are output to the target as a flat list directly under "catalog".
Any groups are discarded.
An example of flat structuring is provided below
{{< highlight xml>}} catalog: groups: @@ -513,7 +510,7 @@as-is
An
as-is
directive is used to reproduce the structure of the source documents in the target catalog.
@@ -555,11 +552,11 @@
custom
The
custom
directive provides the target catalog with a custom structure. A one-to-one mapping of the desired structure of the target catalog is defined alongside control matching instructions, resulting in a strictly controlled output catalog.
-
A +
A
group
object given under
custom
MUST result in a
group
with the exact same content (excluding
@@ -571,12 +568,12 @@
part
objects MUST be copied into the target, appearing in the same order as in the source.
Note that groups defined in
custom
may vary from fully featured to minimally instantiated. This includes arbitrary nesting of such groups inside of one another. No groups other than those explicitly declared should appear in the output catalog.
-
The +
The
insert-controls
directive may appear anywhere under
custom
, whether as a direct child or inside any of the defined groups. Inside insert-controls,
include-controls
and
include-all
from the Import Phase
- [See: Import Phase]are used with the same basic behavior to configure which controls are selected and inserted at the current location.
+ [See: Import Phase]are used with the same basic behavior to configure which controls are selected and inserted at the current location.
In order to provide clarity, controls that match the various conditions of these inclusion directives inside the
custom
object will be referred to as "selected" instead of "included". Only directly selected controls will appear in the target catalog.
When processing the control selection of a custom
element, the behavior defined in this section MUST be followed to generate the output.
A @@ -602,22 +599,22 @@
descending
will sort all selected controls into descending alphanumeric order by their ID.
keep
indicates that controls should be inserted in the order of their appearance, using a depth-first traversal of the source profile's imports.
-
In the case that a control selection matches none of the included controls, it MUST be ignored. In the case that a control selection matches none of the included controls, a warning SHOULD be provided. If a control that was included by the Import Phase is never selected, no error occurs. That control simply does not appear in the output catalog.
After the merge phase, the intermediate should now closely resemble the content and structure of the final output catalog. Controls and groups have been included, remapped, de-duplicated, then placed into their final location within the output's structure. Note: there is still an opportunity for included controls or groups to become referenced; and therefore, not eligible for pruning - [See: Pruning and Ordering]in the next phase. -
Regardless of any merge directives, there also likely remains "loose params" that have been propagated forward; these too must be persisted.
There are two ways profiles may further modify the results of profile resolution: setting parameters and altering controls. These activities are defined as two child objects inside the third step of profile resolution, the Modify Phase.
The following section contains requirements for processing the +
In the case that a control selection matches none of the included controls, it MUST be ignored. In the case that a control selection matches none of the included controls, a warning SHOULD be provided. If a control that was included by the Import Phase is never selected, no error occurs. That control simply does not appear in the output catalog.
After the merge phase, the intermediate should now closely resemble the content and structure of the final output catalog. Controls and groups have been included, remapped, de-duplicated, then placed into their final location within the output's structure. Note: there is still an opportunity for included controls or groups to become referenced; and therefore, not eligible for pruning + [See: Pruning and Ordering]in the next phase. +
Regardless of any merge directives, there also likely remains "loose params" that have been propagated forward; these too must be persisted.
There are two ways profiles may further modify the results of profile resolution: setting parameters and altering controls. These activities are defined as two child objects inside the third step of profile resolution, the Modify Phase.
The following section contains requirements for processing the
modify
child of a source profile.
-
Modification of parameter settings is indicated using the +
Modification of parameter settings is indicated using the
set-parameter
object under
modify
. For this section, a given
set-parameter
object will be referred to as the
source.
-
Profile Resolution Tools MUST adhere to the following requirements for processing "set-parameter":
First, the list of included params (among "loose params" and remaining included controls and groups) is searched for a param who has an "id" equal to this object's "param-id". This is the "target". If no such parameter is found, a warning SHOULD be issued. If no such parameter is found, processing MUST still continue.
For the following objects inside the source: class, depends-on, label, usage, values, select; the object MUST be copied into the target from the source, first removing any existing objects with the same name.
For the following objects inside the source: props, links
, constraints
, guidelines
; the contents of the object MUST be added to the contents of the target object of the same name. If no such object exists in the target, it is created.
For the following objects inside the source: prop
, link
; the object MUST be copied into the target from the source, first removing any existing objects with the same distinctive ID. ([See: Distinct ID of Objects]).
If more than one +
Profile Resolution Tools MUST adhere to the following requirements for processing "set-parameter":
First, the list of included params (among "loose params" and remaining included controls and groups) is searched for a param who has an "id" equal to this object's "param-id". This is the "target". If no such parameter is found, a warning SHOULD be issued. If no such parameter is found, processing MUST still continue.
For the following objects inside the source: class, depends-on, label, usage, values, select; the object MUST be copied into the target from the source, first removing any existing objects with the same name.
For the following objects inside the source: prop
, link
, constraint
, guideline
; the contents of the object MUST be added to the contents of the target object of the same name. If no such object exists in the target, it is created.
For the following objects inside the source: prop
, link
; the object MUST be copied into the target from the source, first removing any existing objects with the same distinctive ID. ([See: Distinct ID of Objects]).
If more than one
set-parameter
directive is given for the same parameter, all MUST BE applied, in the sequence given in the profile.
-
A control can be altered by an +
A control can be altered by an
alter
object inside "modify". The
control-id
child object under the
alter
indicates the control to which the alteration is applied.
-
Contents may be added to controls using an add directive inside an alter directive. There are two forms of alteration: with implicit and explicit bindings.
An +
Contents may be added to controls using an add directive inside an alter directive. There are two forms of alteration: with implicit and explicit bindings.
An
add
directive with no
by-id
child MUST be considered an implicit binding, and will apply to the control as a whole.
The contents of an implicitly bound add directive MUST be added to the control contents in the target, either after its @@ -720,7 +717,7 @@
ending
so the new
prop
appears after the existing
prop
.
- An explicit binding on an addition permits inserting new contents anywhere in a control, not only at the top level. An +
An explicit binding on an addition permits inserting new contents anywhere in a control, not only at the top level. An
add
directive with a
by-id
child MUST be considered an explicit binding, and applies to only a single object inside the control. When an add directive is explicitly bound, the value of the
by-id
child MUST correspond to the value of an
@@ -809,22 +806,23 @@
add
directives, to insert the new
prop
separately before any
part
objects in the target.
- OSCAL supports controls inside controls in the form of
control
objects inside
control
objects. Because the semantics of the
- add
and remove directives target any (object) contents of controls, they can be used to target these child controls for modification as well as other contents. Profile resolution tools MUST be able to correctly handle add directives targetting nested controls. This includes directives that target a child control as well as directives that target a parent control and modify the child.
Contents inside controls can be removed from them in catalog targets. In combination with adding new contents, this feature can be used to edit controls as well as amend them.
A
+ add
and remove directives target any (object) contents of controls, they can be used to target these child controls for modification as well as other contents. Profile resolution tools MUST be able to correctly handle add directives targetting nested controls. This includes directives that target a child control as well as directives that target a parent control and modify the child.
Contents inside controls can be removed from them in catalog targets. In combination with adding new contents, this feature can be used to edit controls as well as amend them.
A
remove
directive inside an
alter
directive identifies an object or set of objects inside a control to be removed. It does this using any of five child objects.
An object inside the control MUST be removed from the output if and only if it meets all of the criteria given by the child objects of the remove directive. When more than one child appears under the remove directive, an object would need to match all of them, otherwise it is not removed.
- The remove directive criteria by-id
MUST match an object if and only if its value is identical to the id
value of that object. Because
- id
values are unique, this criteria will result in the remove directive removing only a single object.
+ The remove directive criterion by-id
MUST match an object if and only if its value is identical to the id
value of that object. Because
+ id
values are unique, this criterion has the effect of removing a single object.
- The remove directive criteria name-ref
MUST match an object if and only if its value is identical to the value of that object's name
child.
-
The remove directive criteria ns-ref
MUST match an object if and only if its value is identical to the value of that object's ns
child.
The remove directive criteria class-ref
MUST match an object if and only if its value is identical to the value of that object's class
child.
The remove directive criteria item-name
MUST match an object if and only if its value is identical to the value of that object's serialized name. For example,
- remove:item-name:prop
has the effect of removing all
- prop
objects from inside the control.
-
In serialization formats that use arrays of objects in the OSCAL model, an object's name MUST be referenced as singular form of its containing parent array. For example, in the JSON format, remove:item-name:link would remove all of the objects inside of the links
array.
+ The remove directive criterion by-name
MUST match an object if and only if its value is identical to the value of that object's name
child.
+
The remove directive criterion by-ns
MUST match an object if and only if its value is identical to the value of that object's ns
child. This directive
+ is intended to be used in combination with by-name
but may also be used to match all objects assigned to a given namespace (ns
). Note that by-ns="http://csrc.nist.gov/ns/oscal"
will address objects assigned to that namespace by default (where no explicit ns
is given).
The remove directive criterion by-class
MUST match an object if and only if its value is identical to the value of that object's class
child.
The remove directive criterion by-item-name
MUST match an object if and only if its value is identical to the value of that object's serialized name. For example,
+ remove.by-item-name: "prop"
has the effect of removing all
+ prop
objects from inside the control.
+
In serialization formats that represent objects as (unlabeled) members of arrays, an object's name MUST be referenced in its (implicit) singular form, not the name of its containing array. For example, in the JSON format, remove.item-name: "link"
would remove all members of the links
array, along with the array itself (as being empty it would no longer be valid).
back-matter
in the result is produced by combining all objects within
back-matter
in all source catalogs, with the
back-matter
in the input profile.
@@ -832,37 +830,37 @@
resource
has the same
uuid
as a resource that has already been added, the previous resource MUST be removed, and the more recent one added, unless superseded by other requirements.
A resource
with a child prop
of name:keep
and value:always
MUST NOT be replaced by the addition of another resource
, unless the new resource also has a child prop
of name:keep
and value:always
.
Tools MAY check for pruning conditions - [See: Pruning and Ordering] as resources are added as long as the final result is the same as if the pruning had taken place at the end of all resource addition. -
Placing the keep always prop on a resource in a catalog has the effect of ensuring it will always appear in the output produced by any profile importing that catalog, even if nothing links to the resource. This version of the resource will also be the one copied, unless a later-imported catalog or importing profile offers its own version marked to keep always.
The following requirements MUST be followed with regards to the Metadata section of the output catalog:
The output catalog's metadata MUST have a unique top-level UUID (metadata:uuid). This UUID may be generated as seen fit by the tool, as long as it is reasonable to assume it is globally unique. It is RECOMMENDED that tools use a combination of meaningful text and a uniquely generated value (Ex.
- {{sourceprofilename}}-RESOLVED-{{GUIDv5}}
).
-
The value of metadata:version in the target MUST be set with a string that identifies the version of that document. The metadata:version SHOULD be used to track updates to this specific output document.
The value of metadata:oscal-version in the target MUST be set with a string that identifies the version of OSCAL used by this tool to resolve the profile (ex. 1.0.0). This value MUST be determined by compiling the oscal-versions from each imported document and the source profile, and taking the most recent minor version. If this version is more recent than what the resolution tool is using, then the value of oscal-version MUST be the version that the tool used internally. If any of the above OSCAL versions (imported document versions, source profile version, tool version) are of a different major version (the first digit differs), the tool SHOULD provide an error and cease processing.
The value of metadata:last-modified in the target MUST be set with a valid timestamp representing the time the profile resolution completed.
The value of metadata:source-profile in the target SHOULD be set with a valid URI that points to the profile that resulted in this catalog. If there are privacy or security concerns, the value of metadata:source-profile MAY be set to anything, in which case the simple existence of the source-profile property indicates that this is a resolved profile.
The value of metadata:resolution-tool in the target SHOULD be set with a string that represents the tool that was used to resolve this catalog.
For any metadata:roles or metadata:parties that exist in the source catalogs, if they have a prop
child with name:keep and value:always, they are to be copied as is into the output metadata.
Beyond these requirements, tools are free to use any and all of the objects inside metadata to provide additional information downstream.
Because of options in producing metadata and especially the requirement for a timestamp, developers and users should note that two different resolutions of the same profile will not, ordinarily, be identical inside + [See: Pruning and Ordering] as resources are added as long as the final result is the same as if the pruning had taken place at the end of all resource addition. +
Placing the keep always prop on a resource in a catalog has the effect of ensuring it will always appear in the output produced by any profile importing that catalog, even if nothing links to the resource. This version of the resource will also be the one copied, unless a later-imported catalog or importing profile offers its own version marked to keep always.
The following requirements MUST be followed with regards to the Metadata section of the output catalog:
The output catalog's metadata MUST have a unique top-level UUID (metadata:uuid). This UUID MAY be generated as seen fit by the tool, as long as it is reasonable to assume it is globally unique. It is RECOMMENDED that tools use a Version 4 UUID as specified in Section 4 of RFC 4122. +
The value of metadata:version in the target MUST be set with a string that identifies the version of that document. The metadata:version SHOULD be used to track updates to this specific output document.
The value of metadata:oscal-version in the target MUST be set to the value of the corresponding object (oscal-version) in the source profile.
If, in processing, a resolver encounters an imported profile or catalog source whose stated oscal-version denotes a version after the oscal-version of the profile, the resolver MAY report a fatal processing error and stop processing. "After" is defined according to the [precedence rules](https://semver.org/#spec-item-11) of Semantic Versioning 2.0, in which 1.0.1 is after 1.0.1-draft.
The value of metadata:last-modified in the target MUST be set with a valid timestamp representing the time the profile resolution completed.
A child prop
object with name:source-profile
MUST be created. The value
object of this prop
SHOULD be set with a valid URI that points to the profile that resulted in this catalog.
+ If there are privacy or security concerns, the value
object of this prop
MAY be set to anything, in which case the simple existence of the source-profile property indicates that this is a resolved profile.
A child prop
object with name:resolution-tool
SHOULD be created. The value
object of this prop
in the target SHOULD be set with a string that represents the tool that was used to resolve this catalog.
For any metadata:roles or metadata:parties that exist in the source catalogs, if they have a prop
child with name:keep and value:always, they are to be copied as is into the output metadata.
Beyond these requirements, tools are free to use any and all of the objects inside metadata to provide additional information downstream.
Because of options in producing metadata and especially the requirement for a timestamp, developers and users should note that two different resolutions of the same profile will not, ordinarily, be identical inside
metadata
.
-
The processor SHOULD prune the resulting output catalog by removing unused objects.
Any object that has a child prop
with a name
of "keep" and a value
of "always" MUST NOT be pruned.
If an object was explicitly included in the - [See: Including Controls], it MUST NOT be pruned. +
The processor SHOULD prune the resulting output catalog by removing unused objects.
Any object that has a child prop
with a name
of "keep" and a value
of "always" MUST NOT be pruned.
If an object was explicitly included in the + [See: Including Controls], it MUST NOT be pruned.
If an object was referenced in a custom
section of the source profile, it MUST NOT be pruned.
If an object was referenced in the modify
section of the source profile, it MUST NOT be pruned. Any objects removed in that section are still removed.
If the object appears in a reference anywhere in the final result catalog, except in other objects that also meet all other pruning criteria, it MUST NOT be removed. A reference to a given object exists if #{distinctiveID}
appears anywhere, where {distinctiveID}
is the distinctive ID of the object
- [See: Distinct ID of Objects].
+ [See: Distinct ID of Objects].
Implementers should note that pruning need not take place after all other steps. As long as all above criteria are respected, pruning can happen at any time, and doing so is a likely performance and memory overhead improvement.
Tools MUST reorder the output catalog into canonical order - [See: Order of objects in serialization], except where this specification provides different ordering requirements. -
Whenever this specification refers to + [See: Order of objects in serialization], except where this specification provides different ordering requirements. +
Whenever this specification refers to "distinctiveness", it is to be interpreted as is defined in this section with regards to the object in question.
For the objects control, param, and group, distinctiveness MUST be determined by the value of the "id" child object.
For the object resource, distinctiveness MUST be determined by the value of the "uuid" - [See: Backmatter Resolution]. -
Profile Resolution tools SHOULD be able to handle source profiles, imported catalogs, and imported profiles that are serialized in XML, JSON, or YAML. A different serialization format of any given input MUST NOT result in a differing output catalog.
In order to help bootstrap this format management, the following resources are provided for implementers:
. + [See: Backmatter Resolution]. +
Profile Resolution tools SHOULD be able to handle source profiles, imported catalogs, and imported profiles that are serialized in XML, JSON, or YAML. A different serialization format of any given input MUST NOT result in a differing output catalog.
In order to help bootstrap this format management, the following resources are provided for implementers:
. -
The following sections provide additional requirements and guidance for each format.
The final Catalog output, if using XML, MUST be valid as defined by the XML model documentation for the OSCAL Catalog. See +
The following sections provide additional requirements and guidance for each format.
The final Catalog output, if using XML, MUST be valid as defined by the XML model documentation for the OSCAL Catalog. See the complete XML reference for model requirements. -
The final Catalog output, if using JSON, MUST be valid as defined by the JSON model documentation for the OSCAL Catalog. See the +
The final Catalog output, if using JSON, MUST be valid as defined by the JSON model documentation for the OSCAL Catalog. See the complete JSON reference for model requirements. -
The JSON format, in general use, does not require the preservation of order of fields. As order matters in OSCAL, care should be taken to adhere to the canonical OSCAL order - [See: Order of objects in serialization] when outputting a catalog in JSON. -
The final Catalog output, if using YAML, MUST be valid as defined by the JSON model documentation for the OSCAL Catalog. YAML is considered a simple variation on the JSON format. Beyond cosmetic differences there are no differences in the information structure between these formats. Therefore, the +
The JSON format, in general use, does not require the preservation of order of fields. As order matters in OSCAL, tools SHOULD adhere to the canonical OSCAL order + [See: Order of objects in serialization] when outputting a catalog in JSON. +
The final Catalog output, if using YAML, MUST be valid as defined by the JSON model documentation for the OSCAL Catalog. YAML is considered a simple variation on the JSON format. Beyond cosmetic differences there are no differences in the information structure between these formats. Therefore, the complete JSON reference provides model requirements. -
The YAML format, in general use, does not require the preservation of order of fields. As order matters in OSCAL, care should be taken to adhere to the canonical OSCAL order - [See: Order of objects in serialization]when outputting a catalog in YAML. -
In OSCAL, order of top level objects (those that are direct children of the root element) is considered important only when the XML format is used. To facilitate this, OSCAL provides the concept of +
The YAML format, in general use, does not require the preservation of order of fields. As order matters in OSCAL, tools SHOULD adhere to the canonical OSCAL order + [See: Order of objects in serialization] when outputting a catalog in YAML. +
In OSCAL, order of top level objects (those that are direct children of the root element) is considered important only when the XML format is used. To facilitate this, OSCAL provides the concept of canonical order. This order is provided by the OSCAL Metaschema files for a given document type (see an overview of Metaschema. -
When the output format is XML, tools MUST use the OSCAL canonical order as described above. When using the YAML or JSON formats, order conveys no meaning, and is not considered important.
In an XML-based profile resolution, XML comments are one straightforward way for a processor to record events or conditions without affecting the output's nominal semantics. To support this, while two processors are obliged to return the same catalog XML for the same profile XML inputs, they are not required to match one another's comments, white space usage, attribute order, or processing instructions, only each other's objects, attributes and data content.
One consequence of this is that processes intended to compare two profile resolutions may have to accommodate differences in comments, considering them as insignificant along with other differences in serialization.
\ No newline at end of file +When the output format is XML, tools MUST use the OSCAL canonical order as described above. When using the YAML or JSON formats, order conveys no meaning, and is not considered important.
In an XML-based profile resolution, XML comments are one straightforward way for a processor to record events or conditions without affecting the output's nominal semantics. To support this, while two processors are obliged to return the same catalog XML for the same profile XML inputs, they are not required to match one another's comments, white space usage, attribute order, or processing instructions, only each other's objects, attributes and data content.
One consequence of this is that processes intended to compare two profile resolutions may have to accommodate differences in comments, considering them as insignificant along with other differences in serialization.
\ No newline at end of file diff --git a/docs/content/reference/develop/_index.md b/docs/content/reference/develop/_index.md index 5287db5616..88ad589c90 100644 --- a/docs/content/reference/develop/_index.md +++ b/docs/content/reference/develop/_index.md @@ -12,7 +12,7 @@ sidenav: oscal: type: "branch" remote: "usnistgov/OSCAL" - branch: "develop" + branch: "1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch" revision: "develop" version: "develop" --- diff --git a/docs/content/reference/develop/assessment-plan/_index.md b/docs/content/reference/develop/assessment-plan/_index.md index de905ebc56..c3504ee51c 100644 --- a/docs/content/reference/develop/assessment-plan/_index.md +++ b/docs/content/reference/develop/assessment-plan/_index.md @@ -11,7 +11,7 @@ sidenav: ---Release Version Latest Development Snapshot
-Github usnistgov/OSCAL Branch develop
+Github usnistgov/OSCAL Branch 1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch
The following reference documentation is available for the OSCAL Assessment Plan model. @@ -19,4 +19,4 @@ The following reference documentation is available for the OSCAL Assessment Plan - **Outline ([JSON/YAML](json-outline/), [XML](xml-outline/)):** Provides a brief listing of the model's information items organized hierarchically. Useful for understanding the structure and basic syntax of the model in a given format. - **Reference ([JSON/YAML](json-reference/), [XML](xml-reference/)):** Provides a detailed description of the structure and syntax for the model's information items organized hierarchically. Useful for understanding how to use information items within the model in the given format. - **Index ([JSON/YAML](json-index/), [XML](xml-index/)):** Provides a listing of the model's information items organized by where they are used. -- **Definitions ([JSON/YAML](json-definitions/), [XML](xml-definitions/)):** Provides a reference for the XML Schema types and JSON Schema definitions derived from this model's [metaschema](https://github.com/usnistgov/OSCAL/blob/develop/src/metaschema/oscal_assessment-plan). A metaschema is used to [express the model](/concepts/layer/overview/#modeling-approach) in a format agnostic way, that is then used to generate the XML and JSON Schema, XML <-> JSON content converters, and this reference documentation. +- **Definitions ([JSON/YAML](json-definitions/), [XML](xml-definitions/)):** Provides a reference for the XML Schema types and JSON Schema definitions derived from this model's [metaschema](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch/src/metaschema/oscal_assessment-plan). A metaschema is used to [express the model](/concepts/layer/overview/#modeling-approach) in a format agnostic way, that is then used to generate the XML and JSON Schema, XML <-> JSON content converters, and this reference documentation. diff --git a/docs/content/reference/develop/assessment-plan/json-definitions.md b/docs/content/reference/develop/assessment-plan/json-definitions.md index e6ddc9f4cd..d67763b0a4 100644 --- a/docs/content/reference/develop/assessment-plan/json-definitions.md +++ b/docs/content/reference/develop/assessment-plan/json-definitions.md @@ -10,7 +10,7 @@ toc: headingselectors: "h1.toc1, h2.toc2, h3.toc3, h4.toc4, h5.toc5, h6.toc6" --- -The following is a reference for the JSON object definitions derived from the [metaschema](https://github.com/usnistgov/OSCAL/blob/develop//src/metaschema/oscal_assessment-plan_metaschema.xml) for this [model](/concepts/layer/assessment/assessment-plan/). +The following is a reference for the JSON object definitions derived from the [metaschema](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch//src/metaschema/oscal_assessment-plan_metaschema.xml) for this [model](/concepts/layer/assessment/assessment-plan/). {{< rawhtml >}} diff --git a/docs/content/reference/develop/assessment-plan/json-index.md b/docs/content/reference/develop/assessment-plan/json-index.md index c1d8496edf..aaa1021923 100644 --- a/docs/content/reference/develop/assessment-plan/json-index.md +++ b/docs/content/reference/develop/assessment-plan/json-index.md @@ -10,7 +10,7 @@ toc: headingselectors: "h1.toc1" --- -The following is an index of each JSON property used in the [JSON format](https://github.com/usnistgov/OSCAL/blob/develop/json/schema/oscal_assessment-plan_schema.json) for this [model](/concepts/layer/assessment/assessment-plan/). Each entry in the index lists all uses of the given property in the format, which is linked to the corresponding entry in the [JSON Format Reference](../json-reference/). Each entry also lists the formal name for the definition which is linked to the corresponding JSON definition in the [JSON Format Metaschema Reference](../json-definitions/). +The following is an index of each JSON property used in the [JSON format](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch/json/schema/oscal_assessment-plan_schema.json) for this [model](/concepts/layer/assessment/assessment-plan/). Each entry in the index lists all uses of the given property in the format, which is linked to the corresponding entry in the [JSON Format Reference](../json-reference/). Each entry also lists the formal name for the definition which is linked to the corresponding JSON definition in the [JSON Format Metaschema Reference](../json-definitions/). {{< rawhtml >}} diff --git a/docs/content/reference/develop/assessment-plan/json-outline.md b/docs/content/reference/develop/assessment-plan/json-outline.md index 5bc0156702..34708e2aaf 100644 --- a/docs/content/reference/develop/assessment-plan/json-outline.md +++ b/docs/content/reference/develop/assessment-plan/json-outline.md @@ -10,7 +10,7 @@ sidenav: --- -The following outline is a representation of the [JSON format](https://github.com/usnistgov/OSCAL/blob/develop/json/schema/oscal_assessment-plan_schema.json) for this [model](/concepts/layer/assessment/assessment-plan/). For each property, the name links to the corresponding entry in the [JSON Format Reference](../json-reference/). The cardinality and data type are also provided for each property where appropriate. +The following outline is a representation of the [JSON format](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch/json/schema/oscal_assessment-plan_schema.json) for this [model](/concepts/layer/assessment/assessment-plan/). For each property, the name links to the corresponding entry in the [JSON Format Reference](../json-reference/). The cardinality and data type are also provided for each property where appropriate. {{< rawhtml >}} diff --git a/docs/content/reference/develop/assessment-plan/xml-definitions.md b/docs/content/reference/develop/assessment-plan/xml-definitions.md index de866e4ac2..105b5ab8b0 100644 --- a/docs/content/reference/develop/assessment-plan/xml-definitions.md +++ b/docs/content/reference/develop/assessment-plan/xml-definitions.md @@ -10,7 +10,7 @@ toc: headingselectors: "h1.toc1, h2.toc2, h3.toc3, h4.toc4, h5.toc5, h6.toc6" --- -The following is a reference for the XML element and attribute types derived from the [metaschema](https://github.com/usnistgov/OSCAL/blob/develop//src/metaschema/oscal_assessment-plan_metaschema.xml) for this [model](/concepts/layer/assessment/assessment-plan/). +The following is a reference for the XML element and attribute types derived from the [metaschema](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch//src/metaschema/oscal_assessment-plan_metaschema.xml) for this [model](/concepts/layer/assessment/assessment-plan/). {{< rawhtml >}}a string value
- - - -</telephone-number>
a string value
- - - -</telephone-number>
a uuid value
- - - - -</member-of-organization>
Release Version Latest Development Snapshot
-Github usnistgov/OSCAL Branch develop
+Github usnistgov/OSCAL Branch 1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch
The following reference documentation is available for the OSCAL Assessment Results model. @@ -19,4 +19,4 @@ The following reference documentation is available for the OSCAL Assessment Resu - **Outline ([JSON/YAML](json-outline/), [XML](xml-outline/)):** Provides a brief listing of the model's information items organized hierarchically. Useful for understanding the structure and basic syntax of the model in a given format. - **Reference ([JSON/YAML](json-reference/), [XML](xml-reference/)):** Provides a detailed description of the structure and syntax for the model's information items organized hierarchically. Useful for understanding how to use information items within the model in the given format. - **Index ([JSON/YAML](json-index/), [XML](xml-index/)):** Provides a listing of the model's information items organized by where they are used. -- **Definitions ([JSON/YAML](json-definitions/), [XML](xml-definitions/)):** Provides a reference for the XML Schema types and JSON Schema definitions derived from this model's [metaschema](https://github.com/usnistgov/OSCAL/blob/develop/src/metaschema/oscal_assessment-results). A metaschema is used to [express the model](/concepts/layer/overview/#modeling-approach) in a format agnostic way, that is then used to generate the XML and JSON Schema, XML <-> JSON content converters, and this reference documentation. +- **Definitions ([JSON/YAML](json-definitions/), [XML](xml-definitions/)):** Provides a reference for the XML Schema types and JSON Schema definitions derived from this model's [metaschema](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch/src/metaschema/oscal_assessment-results). A metaschema is used to [express the model](/concepts/layer/overview/#modeling-approach) in a format agnostic way, that is then used to generate the XML and JSON Schema, XML <-> JSON content converters, and this reference documentation. diff --git a/docs/content/reference/develop/assessment-results/json-definitions.md b/docs/content/reference/develop/assessment-results/json-definitions.md index da9784693a..7b873ebe3b 100644 --- a/docs/content/reference/develop/assessment-results/json-definitions.md +++ b/docs/content/reference/develop/assessment-results/json-definitions.md @@ -10,7 +10,7 @@ toc: headingselectors: "h1.toc1, h2.toc2, h3.toc3, h4.toc4, h5.toc5, h6.toc6" --- -The following is a reference for the JSON object definitions derived from the [metaschema](https://github.com/usnistgov/OSCAL/blob/develop//src/metaschema/oscal_assessment-results_metaschema.xml) for this [model](/concepts/layer/assessment/assessment-results/). +The following is a reference for the JSON object definitions derived from the [metaschema](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch//src/metaschema/oscal_assessment-results_metaschema.xml) for this [model](/concepts/layer/assessment/assessment-results/). {{< rawhtml >}} diff --git a/docs/content/reference/develop/assessment-results/json-index.md b/docs/content/reference/develop/assessment-results/json-index.md index cc2dfa35df..d555bd9eef 100644 --- a/docs/content/reference/develop/assessment-results/json-index.md +++ b/docs/content/reference/develop/assessment-results/json-index.md @@ -10,7 +10,7 @@ toc: headingselectors: "h1.toc1" --- -The following is an index of each JSON property used in the [JSON format](https://github.com/usnistgov/OSCAL/blob/develop/json/schema/oscal_assessment-results_schema.json) for this [model](/concepts/layer/assessment/assessment-results/). Each entry in the index lists all uses of the given property in the format, which is linked to the corresponding entry in the [JSON Format Reference](../json-reference/). Each entry also lists the formal name for the definition which is linked to the corresponding JSON definition in the [JSON Format Metaschema Reference](../json-definitions/). +The following is an index of each JSON property used in the [JSON format](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch/json/schema/oscal_assessment-results_schema.json) for this [model](/concepts/layer/assessment/assessment-results/). Each entry in the index lists all uses of the given property in the format, which is linked to the corresponding entry in the [JSON Format Reference](../json-reference/). Each entry also lists the formal name for the definition which is linked to the corresponding JSON definition in the [JSON Format Metaschema Reference](../json-definitions/). {{< rawhtml >}} diff --git a/docs/content/reference/develop/assessment-results/json-outline.md b/docs/content/reference/develop/assessment-results/json-outline.md index 50919eb97c..c6c90827cb 100644 --- a/docs/content/reference/develop/assessment-results/json-outline.md +++ b/docs/content/reference/develop/assessment-results/json-outline.md @@ -10,7 +10,7 @@ sidenav: --- -The following outline is a representation of the [JSON format](https://github.com/usnistgov/OSCAL/blob/develop/json/schema/oscal_assessment-results_schema.json) for this [model](/concepts/layer/assessment/assessment-results/). For each property, the name links to the corresponding entry in the [JSON Format Reference](../json-reference/). The cardinality and data type are also provided for each property where appropriate. +The following outline is a representation of the [JSON format](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch/json/schema/oscal_assessment-results_schema.json) for this [model](/concepts/layer/assessment/assessment-results/). For each property, the name links to the corresponding entry in the [JSON Format Reference](../json-reference/). The cardinality and data type are also provided for each property where appropriate. {{< rawhtml >}} diff --git a/docs/content/reference/develop/assessment-results/xml-definitions.md b/docs/content/reference/develop/assessment-results/xml-definitions.md index 38abf80dca..081edb14cd 100644 --- a/docs/content/reference/develop/assessment-results/xml-definitions.md +++ b/docs/content/reference/develop/assessment-results/xml-definitions.md @@ -10,7 +10,7 @@ toc: headingselectors: "h1.toc1, h2.toc2, h3.toc3, h4.toc4, h5.toc5, h6.toc6" --- -The following is a reference for the XML element and attribute types derived from the [metaschema](https://github.com/usnistgov/OSCAL/blob/develop//src/metaschema/oscal_assessment-results_metaschema.xml) for this [model](/concepts/layer/assessment/assessment-results/). +The following is a reference for the XML element and attribute types derived from the [metaschema](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch//src/metaschema/oscal_assessment-results_metaschema.xml) for this [model](/concepts/layer/assessment/assessment-results/). {{< rawhtml >}}a string value
- - - -</telephone-number>
a string value
- - - -</telephone-number>
a uuid value
- - - - -</member-of-organization>
a string value
- - An inspection was performed. - An interview was performed. - A manual or automated test was performed. - This is only for use when converting historic content to OSCAL, where the conversion - process cannot initially identify the appropriate method(s). - -</method>
a token value
- - A difference between the SSP implementation statement, and actual implementation. - An observation about the status of a the associated control objective. - A mitigating factor was identified. - An assessment finding. Used for observations made by tools, penetration testing, and - other means. - An observation from a past assessment, which was converted to OSCAL at a later date. - -</type>
a token value
- - The risk has been identified. - The identified risk is being investigated. (Open risk) - Remediation activities are underway, but are not yet complete. (Open risk) - A risk deviation, such as false positive, risk reduction, or operational requirement - has been submitted for approval. (Open risk) - A risk deviation, such as false positive, risk reduction, or operational requirement - has been approved. (Open risk) - The risk has been resolved. - -</status>
a token value
- - The risk has been identified. - The identified risk is being investigated. (Open risk) - Remediation activities are underway, but are not yet complete. (Open risk) - A risk deviation, such as false positive, risk reduction, or operational requirement - has been submitted for approval. (Open risk) - A risk deviation, such as false positive, risk reduction, or operational requirement - has been approved. (Open risk) - The risk has been resolved. - -</status-change>
Release Version Latest Development Snapshot
-Github usnistgov/OSCAL Branch develop
+Github usnistgov/OSCAL Branch 1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch
The following reference documentation is available for the OSCAL Catalog model. @@ -19,4 +19,4 @@ The following reference documentation is available for the OSCAL Catalog model. - **Outline ([JSON/YAML](json-outline/), [XML](xml-outline/)):** Provides a brief listing of the model's information items organized hierarchically. Useful for understanding the structure and basic syntax of the model in a given format. - **Reference ([JSON/YAML](json-reference/), [XML](xml-reference/)):** Provides a detailed description of the structure and syntax for the model's information items organized hierarchically. Useful for understanding how to use information items within the model in the given format. - **Index ([JSON/YAML](json-index/), [XML](xml-index/)):** Provides a listing of the model's information items organized by where they are used. -- **Definitions ([JSON/YAML](json-definitions/), [XML](xml-definitions/)):** Provides a reference for the XML Schema types and JSON Schema definitions derived from this model's [metaschema](https://github.com/usnistgov/OSCAL/blob/develop/src/metaschema/oscal_catalog). A metaschema is used to [express the model](/concepts/layer/overview/#modeling-approach) in a format agnostic way, that is then used to generate the XML and JSON Schema, XML <-> JSON content converters, and this reference documentation. +- **Definitions ([JSON/YAML](json-definitions/), [XML](xml-definitions/)):** Provides a reference for the XML Schema types and JSON Schema definitions derived from this model's [metaschema](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch/src/metaschema/oscal_catalog). A metaschema is used to [express the model](/concepts/layer/overview/#modeling-approach) in a format agnostic way, that is then used to generate the XML and JSON Schema, XML <-> JSON content converters, and this reference documentation. diff --git a/docs/content/reference/develop/catalog/json-definitions.md b/docs/content/reference/develop/catalog/json-definitions.md index 1e82b17ae8..7dc7418de0 100644 --- a/docs/content/reference/develop/catalog/json-definitions.md +++ b/docs/content/reference/develop/catalog/json-definitions.md @@ -10,7 +10,7 @@ toc: headingselectors: "h1.toc1, h2.toc2, h3.toc3, h4.toc4, h5.toc5, h6.toc6" --- -The following is a reference for the JSON object definitions derived from the [metaschema](https://github.com/usnistgov/OSCAL/blob/develop//src/metaschema/oscal_catalog_metaschema.xml) for this [model](/concepts/layer/control/catalog/). +The following is a reference for the JSON object definitions derived from the [metaschema](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch//src/metaschema/oscal_catalog_metaschema.xml) for this [model](/concepts/layer/control/catalog/). {{< rawhtml >}} diff --git a/docs/content/reference/develop/catalog/json-index.md b/docs/content/reference/develop/catalog/json-index.md index 379e9ff63e..86ab183684 100644 --- a/docs/content/reference/develop/catalog/json-index.md +++ b/docs/content/reference/develop/catalog/json-index.md @@ -10,7 +10,7 @@ toc: headingselectors: "h1.toc1" --- -The following is an index of each JSON property used in the [JSON format](https://github.com/usnistgov/OSCAL/blob/develop/json/schema/oscal_catalog_schema.json) for this [model](/concepts/layer/control/catalog/). Each entry in the index lists all uses of the given property in the format, which is linked to the corresponding entry in the [JSON Format Reference](../json-reference/). Each entry also lists the formal name for the definition which is linked to the corresponding JSON definition in the [JSON Format Metaschema Reference](../json-definitions/). +The following is an index of each JSON property used in the [JSON format](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch/json/schema/oscal_catalog_schema.json) for this [model](/concepts/layer/control/catalog/). Each entry in the index lists all uses of the given property in the format, which is linked to the corresponding entry in the [JSON Format Reference](../json-reference/). Each entry also lists the formal name for the definition which is linked to the corresponding JSON definition in the [JSON Format Metaschema Reference](../json-definitions/). {{< rawhtml >}} diff --git a/docs/content/reference/develop/catalog/json-outline.md b/docs/content/reference/develop/catalog/json-outline.md index 5299e785ec..64e2fd3aba 100644 --- a/docs/content/reference/develop/catalog/json-outline.md +++ b/docs/content/reference/develop/catalog/json-outline.md @@ -10,7 +10,7 @@ sidenav: --- -The following outline is a representation of the [JSON format](https://github.com/usnistgov/OSCAL/blob/develop/json/schema/oscal_catalog_schema.json) for this [model](/concepts/layer/control/catalog/). For each property, the name links to the corresponding entry in the [JSON Format Reference](../json-reference/). The cardinality and data type are also provided for each property where appropriate. +The following outline is a representation of the [JSON format](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch/json/schema/oscal_catalog_schema.json) for this [model](/concepts/layer/control/catalog/). For each property, the name links to the corresponding entry in the [JSON Format Reference](../json-reference/). The cardinality and data type are also provided for each property where appropriate. {{< rawhtml >}} diff --git a/docs/content/reference/develop/catalog/xml-definitions.md b/docs/content/reference/develop/catalog/xml-definitions.md index 0e897754db..6894b60521 100644 --- a/docs/content/reference/develop/catalog/xml-definitions.md +++ b/docs/content/reference/develop/catalog/xml-definitions.md @@ -10,7 +10,7 @@ toc: headingselectors: "h1.toc1, h2.toc2, h3.toc3, h4.toc4, h5.toc5, h6.toc6" --- -The following is a reference for the XML element and attribute types derived from the [metaschema](https://github.com/usnistgov/OSCAL/blob/develop//src/metaschema/oscal_catalog_metaschema.xml) for this [model](/concepts/layer/control/catalog/). +The following is a reference for the XML element and attribute types derived from the [metaschema](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch//src/metaschema/oscal_catalog_metaschema.xml) for this [model](/concepts/layer/control/catalog/). {{< rawhtml >}}a string value
- - - -</telephone-number>
a string value
- - - -</telephone-number>
a uuid value
- - - - -</member-of-organization>
a token value
- - The effective requirements of the source is equivalent in semantic meaning to the - effective requirements of the target. The words may differ, but both mapped sets convey - similar information with the same effective meaning. This relationship may be reversed, - since `A equivalent-to B` also means that `B equivalent-to A`. - The actual requirements of the source are the same as the actual requirements target. - Differences in capitalization, spelling, and grammar can be ignored, if these differences - do not change the meaning. This relationship may be reversed, since `A equal-to B` - also means that `B equal-to A`. - The effective requirements of the source is a semantic subset of the effective requirements - of the target. This relationship may be reversed as a `superset-of`, since `A subset-of - B` also means that `B superset-of A`. - The effective requirements of the source is a semantic superset of the effective requirements - of the target. This relationship may be reversed as a `subset-of`, since `A superset-of - B` also means that `B subset-of A`. - The effective requirements of the source and target have some semantic equivalence, - but not all effective requirements from each are contained within the other. This - relationship may be reversed, since `A intersects-with B` also means that `B intersects-with - A`. A lower granularity mapping, such as a statement level mapping using 'equivalent-to', - 'subset-of', and/or 'superset-of', may provide a more functional mapping that allows - for more inference than using this relationship type. - -</relationship>
a token value
- - The effective requirements of the source is equivalent in semantic meaning to the - effective requirements of the target. The words may differ, but both mapped sets convey - similar information with the same effective meaning. This relationship may be reversed, - since `A equivalent-to B` also means that `B equivalent-to A`. - The actual requirements of the source are the same as the actual requirements target. - Differences in capitalization, spelling, and grammar can be ignored, if these differences - do not change the meaning. This relationship may be reversed, since `A equal-to B` - also means that `B equal-to A`. - The effective requirements of the source is a semantic subset of the effective requirements - of the target. This relationship may be reversed as a `superset-of`, since `A subset-of - B` also means that `B superset-of A`. - The effective requirements of the source is a semantic superset of the effective requirements - of the target. This relationship may be reversed as a `subset-of`, since `A superset-of - B` also means that `B subset-of A`. - The effective requirements of the source and target have some semantic equivalence, - but not all effective requirements from each are contained within the other. This - relationship may be reversed, since `A intersects-with B` also means that `B intersects-with - A`. A lower granularity mapping, such as a statement level mapping using 'equivalent-to', - 'subset-of', and/or 'superset-of', may provide a more functional mapping that allows - for more inference than using this relationship type. - -</relationship>
Release Version Latest Development Snapshot
-Github usnistgov/OSCAL Branch develop
+Github usnistgov/OSCAL Branch 1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch
This reference combines the information items used in all the OSCAL models into a single, comprehensive view. The following reference documentation is available. diff --git a/docs/content/reference/develop/complete/json-definitions.md b/docs/content/reference/develop/complete/json-definitions.md index 5a2a759900..f513884400 100644 --- a/docs/content/reference/develop/complete/json-definitions.md +++ b/docs/content/reference/develop/complete/json-definitions.md @@ -10,7 +10,7 @@ toc: headingselectors: "h1.toc1, h2.toc2, h3.toc3, h4.toc4, h5.toc5, h6.toc6" --- -The following is a reference for the JSON object definitions derived from this model's [metaschema](https://github.com/usnistgov/OSCAL/blob/develop/src/metaschema/oscal_complete_metaschema.xml), which imports the metaschemas for all of the OSCAL models. +The following is a reference for the JSON object definitions derived from this model's [metaschema](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch/src/metaschema/oscal_complete_metaschema.xml), which imports the metaschemas for all of the OSCAL models. {{< rawhtml >}} @@ -8576,7 +8576,7 @@ The following is a reference for the JSON object definitions derived from this mallowed value for (.|statement|.//by-component)/prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal')]/@name
allowed value for prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal')]/@name
The value must be one of the following:
-allowed values for responsible-role/@role-id
The value may be locally defined, or one of the following:
@@ -8928,7 +8918,7 @@ The following is a reference for the JSON object definitions derived from this massembly
Select Control
use name include-controls
group as include-controls
description Select a control or controls from an imported control set.
If with-child-controls
is yes
on the call to a control, no sibling call
elements need to be used to call any controls appearing within it. Since generally,
- this is how control enhancements are represented (as controls within controls), this
- provides a way to include controls with all their dependent controls (enhancements)
- without having to call them individually.
Identifies a subset of controls to import from the referenced catalog or profile by - control identifier or match pattern.
+If with-child-controls
is yes
on the call to a control, any controls appearing within it (child controls) will
+ be selected, with no additional call
directives required. This flag provides a way to include controls with all their
+ dependent controls (enhancements) without having to call them individually.
If with-parent-controls is "yes" on the call to a control, it will not be selected + and removed from (shown without) a parent control, but instead will be copied with + its parent in the source. This flag provides a way to include controls with all their + ancestor controls (enhancements) without having to call them individually.
[0 or 1]
+ +Include Contained Controls with Control
+group as with-ids
group as matching
description Selecting a set of controls by matching their IDs with a wildcard pattern.
+Match Controls by Identifier
assembly
Match Controls by Pattern
description Selecting a set of controls by matching their IDs with a wildcard pattern.
group as matching
description Selecting a control by its ID given as a literal.
+description When a control is included, whether its parent (ancestor) controls are also included.
+allowed values
+The value must be one of the following:
+An array of include-controls objects [1 to ∞] {
-with-child-controls [0 or 1]: token,
+with-parent-controls [0 or 1]: token,
+]
+}
If with-child-controls
is yes
on the call to a control, no sibling call
elements need to be used to call any controls appearing within it. Since generally,
- this is how control enhancements are represented (as controls within controls), this
- provides a way to include controls with all their dependent controls (enhancements)
- without having to call them individually.
Identifies a subset of controls to import from the referenced catalog or profile by - control identifier or match pattern.
+If with-child-controls
is yes
on the call to a control, any controls appearing within it (child controls) will
+ be selected, with no additional call
directives required. This flag provides a way to include controls with all their
+ dependent controls (enhancements) without having to call them individually.
If with-parent-controls is "yes" on the call to a control, it will not be selected + and removed from (shown without) a parent control, but instead will be copied with + its parent in the source. This flag provides a way to include controls with all their + ancestor controls (enhancements) without having to call them individually.
Description When a control is included, whether its parent (ancestor) controls are also included.
+allowed values
+The value must be one of the following:
+allowed value for (.|statement|.//by-component)/prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal')]/@name
The value must be one of the following:
@@ -61468,15 +61488,6 @@ The following is the JSON format reference for the combination of all OSCAL modeallowed value for prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal')]/@name
The value must be one of the following:
-allowed values for responsible-role/@role-id
The value may be locally defined, or one of the following:
diff --git a/docs/content/reference/develop/complete/xml-definitions.md b/docs/content/reference/develop/complete/xml-definitions.md index 64b4f835f5..a8a341a4b4 100644 --- a/docs/content/reference/develop/complete/xml-definitions.md +++ b/docs/content/reference/develop/complete/xml-definitions.md @@ -10,7 +10,7 @@ toc: headingselectors: "h1.toc1, h2.toc2, h3.toc3, h4.toc4, h5.toc5, h6.toc6" --- -The following is a reference for the XML element and attribute types derived from this model's [metaschema](https://github.com/usnistgov/OSCAL/blob/develop/src/metaschema/oscal_complete_metaschema.xml). +The following is a reference for the XML element and attribute types derived from this model's [metaschema](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch/src/metaschema/oscal_complete_metaschema.xml). {{< rawhtml >}}allowed value for (.|statement|.//by-component)/prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal')]/@name
allowed value for prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal')]/@name
The value must be one of the following:
-allowed values for responsible-role/@role-id
The value may be locally defined, or one of the following:
@@ -8925,7 +8915,7 @@ The following is a reference for the XML element and attribute types derived froassembly
Select Control
use name include-controls
description Select a control or controls from an imported control set.
If with-child-controls
is yes
on the call to a control, no sibling call
elements need to be used to call any controls appearing within it. Since generally,
- this is how control enhancements are represented (as controls within controls), this
- provides a way to include controls with all their dependent controls (enhancements)
- without having to call them individually.
Identifies a subset of controls to import from the referenced catalog or profile by - control identifier or match pattern.
+If with-child-controls
is yes
on the call to a control, any controls appearing within it (child controls) will
+ be selected, with no additional call
directives required. This flag provides a way to include controls with all their
+ dependent controls (enhancements) without having to call them individually.
If with-parent-controls is "yes" on the call to a control, it will not be selected + and removed from (shown without) a parent control, but instead will be copied with + its parent in the source. This flag provides a way to include controls with all their + ancestor controls (enhancements) without having to call them individually.
[0 or 1]
+ +Include Contained Controls with Control
+description Selecting a set of controls by matching their IDs with a wildcard pattern.
+Match Controls by Identifier
description Selecting a control by its ID given as a literal.
+assembly
Match Controls by Pattern
description Selecting a set of controls by matching their IDs with a wildcard pattern.
-description Selecting a control by its ID given as a literal.
+description When a control is included, whether its parent (ancestor) controls are also included.
+allowed values
+The value must be one of the following:
+a string value
- - - -</telephone-number>
a string value
- - - -</telephone-number>
a uuid value
- - - - -</member-of-organization>
a token value
- - The effective requirements of the source is equivalent in semantic meaning to the - effective requirements of the target. The words may differ, but both mapped sets convey - similar information with the same effective meaning. This relationship may be reversed, - since `A equivalent-to B` also means that `B equivalent-to A`. - The actual requirements of the source are the same as the actual requirements target. - Differences in capitalization, spelling, and grammar can be ignored, if these differences - do not change the meaning. This relationship may be reversed, since `A equal-to B` - also means that `B equal-to A`. - The effective requirements of the source is a semantic subset of the effective requirements - of the target. This relationship may be reversed as a `superset-of`, since `A subset-of - B` also means that `B superset-of A`. - The effective requirements of the source is a semantic superset of the effective requirements - of the target. This relationship may be reversed as a `subset-of`, since `A superset-of - B` also means that `B subset-of A`. - The effective requirements of the source and target have some semantic equivalence, - but not all effective requirements from each are contained within the other. This - relationship may be reversed, since `A intersects-with B` also means that `B intersects-with - A`. A lower granularity mapping, such as a statement level mapping using 'equivalent-to', - 'subset-of', and/or 'superset-of', may provide a more functional mapping that allows - for more inference than using this relationship type. - -</relationship>
a token value
- - The effective requirements of the source is equivalent in semantic meaning to the - effective requirements of the target. The words may differ, but both mapped sets convey - similar information with the same effective meaning. This relationship may be reversed, - since `A equivalent-to B` also means that `B equivalent-to A`. - The actual requirements of the source are the same as the actual requirements target. - Differences in capitalization, spelling, and grammar can be ignored, if these differences - do not change the meaning. This relationship may be reversed, since `A equal-to B` - also means that `B equal-to A`. - The effective requirements of the source is a semantic subset of the effective requirements - of the target. This relationship may be reversed as a `superset-of`, since `A subset-of - B` also means that `B superset-of A`. - The effective requirements of the source is a semantic superset of the effective requirements - of the target. This relationship may be reversed as a `subset-of`, since `A superset-of - B` also means that `B subset-of A`. - The effective requirements of the source and target have some semantic equivalence, - but not all effective requirements from each are contained within the other. This - relationship may be reversed, since `A intersects-with B` also means that `B intersects-with - A`. A lower granularity mapping, such as a statement level mapping using 'equivalent-to', - 'subset-of', and/or 'superset-of', may provide a more functional mapping that allows - for more inference than using this relationship type. - -</relationship>
a string value
- - - -</telephone-number>
a string value
- - - -</telephone-number>
a uuid value
- - - - -</member-of-organization>
a token value
- - The effective requirements of the source is equivalent in semantic meaning to the - effective requirements of the target. The words may differ, but both mapped sets convey - similar information with the same effective meaning. This relationship may be reversed, - since `A equivalent-to B` also means that `B equivalent-to A`. - The actual requirements of the source are the same as the actual requirements target. - Differences in capitalization, spelling, and grammar can be ignored, if these differences - do not change the meaning. This relationship may be reversed, since `A equal-to B` - also means that `B equal-to A`. - The effective requirements of the source is a semantic subset of the effective requirements - of the target. This relationship may be reversed as a `superset-of`, since `A subset-of - B` also means that `B superset-of A`. - The effective requirements of the source is a semantic superset of the effective requirements - of the target. This relationship may be reversed as a `subset-of`, since `A superset-of - B` also means that `B subset-of A`. - The effective requirements of the source and target have some semantic equivalence, - but not all effective requirements from each are contained within the other. This - relationship may be reversed, since `A intersects-with B` also means that `B intersects-with - A`. A lower granularity mapping, such as a statement level mapping using 'equivalent-to', - 'subset-of', and/or 'superset-of', may provide a more functional mapping that allows - for more inference than using this relationship type. - -</relationship>
a string value
- - - -</telephone-number>
a string value
- - - -</telephone-number>
a uuid value
- - - - -</member-of-organization>
a string value
- - - -</telephone-number>
a string value
- - - -</telephone-number>
a uuid value
- - - - -</member-of-organization>
a string value
- - - -</telephone-number>
a string value
- - - -</telephone-number>
a uuid value
- - - - -</member-of-organization>
a string value
- - - -</telephone-number>
a string value
- - - -</telephone-number>
a uuid value
- - - - -</member-of-organization>
a string value
- - - -</telephone-number>
a string value
- - - -</telephone-number>
a uuid value
- - - - -</member-of-organization>
a string value
- - An inspection was performed. - An interview was performed. - A manual or automated test was performed. - This is only for use when converting historic content to OSCAL, where the conversion - process cannot initially identify the appropriate method(s). - -</method>
a token value
- - A difference between the SSP implementation statement, and actual implementation. - An observation about the status of a the associated control objective. - A mitigating factor was identified. - An assessment finding. Used for observations made by tools, penetration testing, and - other means. - An observation from a past assessment, which was converted to OSCAL at a later date. - -</type>
a token value
- - The risk has been identified. - The identified risk is being investigated. (Open risk) - Remediation activities are underway, but are not yet complete. (Open risk) - A risk deviation, such as false positive, risk reduction, or operational requirement - has been submitted for approval. (Open risk) - A risk deviation, such as false positive, risk reduction, or operational requirement - has been approved. (Open risk) - The risk has been resolved. - -</status>
a token value
- - The risk has been identified. - The identified risk is being investigated. (Open risk) - Remediation activities are underway, but are not yet complete. (Open risk) - A risk deviation, such as false positive, risk reduction, or operational requirement - has been submitted for approval. (Open risk) - A risk deviation, such as false positive, risk reduction, or operational requirement - has been approved. (Open risk) - The risk has been resolved. - -</status-change>
a string value
- - - -</telephone-number>
a string value
- - - -</telephone-number>
a uuid value
- - - - -</member-of-organization>
a string value
- - An inspection was performed. - An interview was performed. - A manual or automated test was performed. - This is only for use when converting historic content to OSCAL, where the conversion - process cannot initially identify the appropriate method(s). - -</method>
a token value
- - A difference between the SSP implementation statement, and actual implementation. - An observation about the status of a the associated control objective. - A mitigating factor was identified. - An assessment finding. Used for observations made by tools, penetration testing, and - other means. - An observation from a past assessment, which was converted to OSCAL at a later date. - -</type>
a token value
- - The risk has been identified. - The identified risk is being investigated. (Open risk) - Remediation activities are underway, but are not yet complete. (Open risk) - A risk deviation, such as false positive, risk reduction, or operational requirement - has been submitted for approval. (Open risk) - A risk deviation, such as false positive, risk reduction, or operational requirement - has been approved. (Open risk) - The risk has been resolved. - -</status>
a token value
- - The risk has been identified. - The identified risk is being investigated. (Open risk) - Remediation activities are underway, but are not yet complete. (Open risk) - A risk deviation, such as false positive, risk reduction, or operational requirement - has been submitted for approval. (Open risk) - A risk deviation, such as false positive, risk reduction, or operational requirement - has been approved. (Open risk) - The risk has been resolved. - -</status-change>
If with-child-controls
is yes
on the call to a control, no sibling call
elements need to be used to call any controls appearing within it. Since generally,
- this is how control enhancements are represented (as controls within controls), this
- provides a way to include controls with all their dependent controls (enhancements)
- without having to call them individually.
Identifies a subset of controls to import from the referenced catalog or profile by - control identifier or match pattern.
+If with-child-controls
is yes
on the call to a control, any controls appearing within it (child controls) will
+ be selected, with no additional call
directives required. This flag provides a way to include controls with all their
+ dependent controls (enhancements) without having to call them individually.
If with-parent-controls is "yes" on the call to a control, it will not be selected + and removed from (shown without) a parent control, but instead will be copied with + its parent in the source. This flag provides a way to include controls with all their + ancestor controls (enhancements) without having to call them individually.
Description When a control is included, whether its parent (ancestor) controls are also included.
+allowed values
+The value must be one of the following:
+allowed value for (.|statement|.//by-component)/prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal')]/@name
The value must be one of the following:
@@ -63305,15 +63330,6 @@ The following is the XML format reference for the combination of all OSCAL modelallowed value for prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal')]/@name
The value must be one of the following:
-allowed values for responsible-role/@role-id
The value may be locally defined, or one of the following:
diff --git a/docs/content/reference/develop/component-definition/_index.md b/docs/content/reference/develop/component-definition/_index.md index e3a8ed7a20..418caf1c61 100644 --- a/docs/content/reference/develop/component-definition/_index.md +++ b/docs/content/reference/develop/component-definition/_index.md @@ -11,7 +11,7 @@ sidenav: ---Release Version Latest Development Snapshot
-Github usnistgov/OSCAL Branch develop
+Github usnistgov/OSCAL Branch 1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch
The following reference documentation is available for the OSCAL Component Definition model. @@ -19,4 +19,4 @@ The following reference documentation is available for the OSCAL Component Defin - **Outline ([JSON/YAML](json-outline/), [XML](xml-outline/)):** Provides a brief listing of the model's information items organized hierarchically. Useful for understanding the structure and basic syntax of the model in a given format. - **Reference ([JSON/YAML](json-reference/), [XML](xml-reference/)):** Provides a detailed description of the structure and syntax for the model's information items organized hierarchically. Useful for understanding how to use information items within the model in the given format. - **Index ([JSON/YAML](json-index/), [XML](xml-index/)):** Provides a listing of the model's information items organized by where they are used. -- **Definitions ([JSON/YAML](json-definitions/), [XML](xml-definitions/)):** Provides a reference for the XML Schema types and JSON Schema definitions derived from this model's [metaschema](https://github.com/usnistgov/OSCAL/blob/develop/src/metaschema/oscal_component-definition). A metaschema is used to [express the model](/concepts/layer/overview/#modeling-approach) in a format agnostic way, that is then used to generate the XML and JSON Schema, XML <-> JSON content converters, and this reference documentation. +- **Definitions ([JSON/YAML](json-definitions/), [XML](xml-definitions/)):** Provides a reference for the XML Schema types and JSON Schema definitions derived from this model's [metaschema](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch/src/metaschema/oscal_component-definition). A metaschema is used to [express the model](/concepts/layer/overview/#modeling-approach) in a format agnostic way, that is then used to generate the XML and JSON Schema, XML <-> JSON content converters, and this reference documentation. diff --git a/docs/content/reference/develop/component-definition/json-definitions.md b/docs/content/reference/develop/component-definition/json-definitions.md index 218a345b2e..495d912759 100644 --- a/docs/content/reference/develop/component-definition/json-definitions.md +++ b/docs/content/reference/develop/component-definition/json-definitions.md @@ -10,7 +10,7 @@ toc: headingselectors: "h1.toc1, h2.toc2, h3.toc3, h4.toc4, h5.toc5, h6.toc6" --- -The following is a reference for the JSON object definitions derived from the [metaschema](https://github.com/usnistgov/OSCAL/blob/develop//src/metaschema/oscal_component-definition_metaschema.xml) for this [model](/concepts/layer/implementation/component-definition/). +The following is a reference for the JSON object definitions derived from the [metaschema](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch//src/metaschema/oscal_component-definition_metaschema.xml) for this [model](/concepts/layer/implementation/component-definition/). {{< rawhtml >}} diff --git a/docs/content/reference/develop/component-definition/json-index.md b/docs/content/reference/develop/component-definition/json-index.md index af2eaee8f4..9bc7ca6b8b 100644 --- a/docs/content/reference/develop/component-definition/json-index.md +++ b/docs/content/reference/develop/component-definition/json-index.md @@ -10,7 +10,7 @@ toc: headingselectors: "h1.toc1" --- -The following is an index of each JSON property used in the [JSON format](https://github.com/usnistgov/OSCAL/blob/develop/json/schema/oscal_component-definition_schema.json) for this [model](/concepts/layer/implementation/component-definition/). Each entry in the index lists all uses of the given property in the format, which is linked to the corresponding entry in the [JSON Format Reference](../json-reference/). Each entry also lists the formal name for the definition which is linked to the corresponding JSON definition in the [JSON Format Metaschema Reference](../json-definitions/). +The following is an index of each JSON property used in the [JSON format](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch/json/schema/oscal_component-definition_schema.json) for this [model](/concepts/layer/implementation/component-definition/). Each entry in the index lists all uses of the given property in the format, which is linked to the corresponding entry in the [JSON Format Reference](../json-reference/). Each entry also lists the formal name for the definition which is linked to the corresponding JSON definition in the [JSON Format Metaschema Reference](../json-definitions/). {{< rawhtml >}} diff --git a/docs/content/reference/develop/component-definition/json-outline.md b/docs/content/reference/develop/component-definition/json-outline.md index 644b99cd59..5cdfe9c78d 100644 --- a/docs/content/reference/develop/component-definition/json-outline.md +++ b/docs/content/reference/develop/component-definition/json-outline.md @@ -10,7 +10,7 @@ sidenav: --- -The following outline is a representation of the [JSON format](https://github.com/usnistgov/OSCAL/blob/develop/json/schema/oscal_component-definition_schema.json) for this [model](/concepts/layer/implementation/component-definition/). For each property, the name links to the corresponding entry in the [JSON Format Reference](../json-reference/). The cardinality and data type are also provided for each property where appropriate. +The following outline is a representation of the [JSON format](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch/json/schema/oscal_component-definition_schema.json) for this [model](/concepts/layer/implementation/component-definition/). For each property, the name links to the corresponding entry in the [JSON Format Reference](../json-reference/). The cardinality and data type are also provided for each property where appropriate. {{< rawhtml >}} diff --git a/docs/content/reference/develop/component-definition/xml-definitions.md b/docs/content/reference/develop/component-definition/xml-definitions.md index 2f37967fd7..f6e321927a 100644 --- a/docs/content/reference/develop/component-definition/xml-definitions.md +++ b/docs/content/reference/develop/component-definition/xml-definitions.md @@ -10,7 +10,7 @@ toc: headingselectors: "h1.toc1, h2.toc2, h3.toc3, h4.toc4, h5.toc5, h6.toc6" --- -The following is a reference for the XML element and attribute types derived from the [metaschema](https://github.com/usnistgov/OSCAL/blob/develop//src/metaschema/oscal_component-definition_metaschema.xml) for this [model](/concepts/layer/implementation/component-definition/). +The following is a reference for the XML element and attribute types derived from the [metaschema](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch//src/metaschema/oscal_component-definition_metaschema.xml) for this [model](/concepts/layer/implementation/component-definition/). {{< rawhtml >}}a string value
- - - -</telephone-number>
a string value
- - - -</telephone-number>
a uuid value
- - - - -</member-of-organization>
Release Version Latest Development Snapshot
-Github usnistgov/OSCAL Branch develop
+Github usnistgov/OSCAL Branch 1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch
The following reference documentation is available for the OSCAL Control Mapping model. @@ -19,4 +19,4 @@ The following reference documentation is available for the OSCAL Control Mapping - **Outline ([JSON/YAML](json-outline/), [XML](xml-outline/)):** Provides a brief listing of the model's information items organized hierarchically. Useful for understanding the structure and basic syntax of the model in a given format. - **Reference ([JSON/YAML](json-reference/), [XML](xml-reference/)):** Provides a detailed description of the structure and syntax for the model's information items organized hierarchically. Useful for understanding how to use information items within the model in the given format. - **Index ([JSON/YAML](json-index/), [XML](xml-index/)):** Provides a listing of the model's information items organized by where they are used. -- **Definitions ([JSON/YAML](json-definitions/), [XML](xml-definitions/)):** Provides a reference for the XML Schema types and JSON Schema definitions derived from this model's [metaschema](https://github.com/usnistgov/OSCAL/blob/develop/src/metaschema/oscal_mapping). A metaschema is used to [express the model](/concepts/layer/overview/#modeling-approach) in a format agnostic way, that is then used to generate the XML and JSON Schema, XML <-> JSON content converters, and this reference documentation. +- **Definitions ([JSON/YAML](json-definitions/), [XML](xml-definitions/)):** Provides a reference for the XML Schema types and JSON Schema definitions derived from this model's [metaschema](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch/src/metaschema/oscal_mapping). A metaschema is used to [express the model](/concepts/layer/overview/#modeling-approach) in a format agnostic way, that is then used to generate the XML and JSON Schema, XML <-> JSON content converters, and this reference documentation. diff --git a/docs/content/reference/develop/mapping/json-definitions.md b/docs/content/reference/develop/mapping/json-definitions.md index 2da55d0347..7615736312 100644 --- a/docs/content/reference/develop/mapping/json-definitions.md +++ b/docs/content/reference/develop/mapping/json-definitions.md @@ -10,7 +10,7 @@ toc: headingselectors: "h1.toc1, h2.toc2, h3.toc3, h4.toc4, h5.toc5, h6.toc6" --- -The following is a reference for the JSON object definitions derived from the [metaschema](https://github.com/usnistgov/OSCAL/blob/develop//src/metaschema/oscal_mapping_metaschema.xml) for this [model](/concepts/layer/control/mapping/). +The following is a reference for the JSON object definitions derived from the [metaschema](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch//src/metaschema/oscal_mapping_metaschema.xml) for this [model](/concepts/layer/control/mapping/). {{< rawhtml >}} diff --git a/docs/content/reference/develop/mapping/json-index.md b/docs/content/reference/develop/mapping/json-index.md index 450037e446..35e016abcf 100644 --- a/docs/content/reference/develop/mapping/json-index.md +++ b/docs/content/reference/develop/mapping/json-index.md @@ -10,7 +10,7 @@ toc: headingselectors: "h1.toc1" --- -The following is an index of each JSON property used in the [JSON format](https://github.com/usnistgov/OSCAL/blob/develop/json/schema/oscal_mapping_schema.json) for this [model](/concepts/layer/control/mapping/). Each entry in the index lists all uses of the given property in the format, which is linked to the corresponding entry in the [JSON Format Reference](../json-reference/). Each entry also lists the formal name for the definition which is linked to the corresponding JSON definition in the [JSON Format Metaschema Reference](../json-definitions/). +The following is an index of each JSON property used in the [JSON format](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch/json/schema/oscal_mapping_schema.json) for this [model](/concepts/layer/control/mapping/). Each entry in the index lists all uses of the given property in the format, which is linked to the corresponding entry in the [JSON Format Reference](../json-reference/). Each entry also lists the formal name for the definition which is linked to the corresponding JSON definition in the [JSON Format Metaschema Reference](../json-definitions/). {{< rawhtml >}} diff --git a/docs/content/reference/develop/mapping/json-outline.md b/docs/content/reference/develop/mapping/json-outline.md index 09504c5aad..6f61ad866a 100644 --- a/docs/content/reference/develop/mapping/json-outline.md +++ b/docs/content/reference/develop/mapping/json-outline.md @@ -10,7 +10,7 @@ sidenav: --- -The following outline is a representation of the [JSON format](https://github.com/usnistgov/OSCAL/blob/develop/json/schema/oscal_mapping_schema.json) for this [model](/concepts/layer/control/mapping/). For each property, the name links to the corresponding entry in the [JSON Format Reference](../json-reference/). The cardinality and data type are also provided for each property where appropriate. +The following outline is a representation of the [JSON format](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch/json/schema/oscal_mapping_schema.json) for this [model](/concepts/layer/control/mapping/). For each property, the name links to the corresponding entry in the [JSON Format Reference](../json-reference/). The cardinality and data type are also provided for each property where appropriate. {{< rawhtml >}} diff --git a/docs/content/reference/develop/mapping/xml-definitions.md b/docs/content/reference/develop/mapping/xml-definitions.md index 3abfc748bd..079fda05a1 100644 --- a/docs/content/reference/develop/mapping/xml-definitions.md +++ b/docs/content/reference/develop/mapping/xml-definitions.md @@ -10,7 +10,7 @@ toc: headingselectors: "h1.toc1, h2.toc2, h3.toc3, h4.toc4, h5.toc5, h6.toc6" --- -The following is a reference for the XML element and attribute types derived from the [metaschema](https://github.com/usnistgov/OSCAL/blob/develop//src/metaschema/oscal_mapping_metaschema.xml) for this [model](/concepts/layer/control/mapping/). +The following is a reference for the XML element and attribute types derived from the [metaschema](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch//src/metaschema/oscal_mapping_metaschema.xml) for this [model](/concepts/layer/control/mapping/). {{< rawhtml >}}a string value
- - - -</telephone-number>
a string value
- - - -</telephone-number>
a uuid value
- - - - -</member-of-organization>
a token value
- - The effective requirements of the source is equivalent in semantic meaning to the - effective requirements of the target. The words may differ, but both mapped sets convey - similar information with the same effective meaning. This relationship may be reversed, - since `A equivalent-to B` also means that `B equivalent-to A`. - The actual requirements of the source are the same as the actual requirements target. - Differences in capitalization, spelling, and grammar can be ignored, if these differences - do not change the meaning. This relationship may be reversed, since `A equal-to B` - also means that `B equal-to A`. - The effective requirements of the source is a semantic subset of the effective requirements - of the target. This relationship may be reversed as a `superset-of`, since `A subset-of - B` also means that `B superset-of A`. - The effective requirements of the source is a semantic superset of the effective requirements - of the target. This relationship may be reversed as a `subset-of`, since `A superset-of - B` also means that `B subset-of A`. - The effective requirements of the source and target have some semantic equivalence, - but not all effective requirements from each are contained within the other. This - relationship may be reversed, since `A intersects-with B` also means that `B intersects-with - A`. A lower granularity mapping, such as a statement level mapping using 'equivalent-to', - 'subset-of', and/or 'superset-of', may provide a more functional mapping that allows - for more inference than using this relationship type. - -</relationship>
Release Version Latest Development Snapshot
-Github usnistgov/OSCAL Branch develop
+Github usnistgov/OSCAL Branch 1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch
The following reference documentation is available for the OSCAL Plan of Action and Milestones model. @@ -19,4 +19,4 @@ The following reference documentation is available for the OSCAL Plan of Action - **Outline ([JSON/YAML](json-outline/), [XML](xml-outline/)):** Provides a brief listing of the model's information items organized hierarchically. Useful for understanding the structure and basic syntax of the model in a given format. - **Reference ([JSON/YAML](json-reference/), [XML](xml-reference/)):** Provides a detailed description of the structure and syntax for the model's information items organized hierarchically. Useful for understanding how to use information items within the model in the given format. - **Index ([JSON/YAML](json-index/), [XML](xml-index/)):** Provides a listing of the model's information items organized by where they are used. -- **Definitions ([JSON/YAML](json-definitions/), [XML](xml-definitions/)):** Provides a reference for the XML Schema types and JSON Schema definitions derived from this model's [metaschema](https://github.com/usnistgov/OSCAL/blob/develop/src/metaschema/oscal_poam). A metaschema is used to [express the model](/concepts/layer/overview/#modeling-approach) in a format agnostic way, that is then used to generate the XML and JSON Schema, XML <-> JSON content converters, and this reference documentation. +- **Definitions ([JSON/YAML](json-definitions/), [XML](xml-definitions/)):** Provides a reference for the XML Schema types and JSON Schema definitions derived from this model's [metaschema](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch/src/metaschema/oscal_poam). A metaschema is used to [express the model](/concepts/layer/overview/#modeling-approach) in a format agnostic way, that is then used to generate the XML and JSON Schema, XML <-> JSON content converters, and this reference documentation. diff --git a/docs/content/reference/develop/plan-of-action-and-milestones/json-definitions.md b/docs/content/reference/develop/plan-of-action-and-milestones/json-definitions.md index be0637bcb1..ca79b1d02a 100644 --- a/docs/content/reference/develop/plan-of-action-and-milestones/json-definitions.md +++ b/docs/content/reference/develop/plan-of-action-and-milestones/json-definitions.md @@ -10,7 +10,7 @@ toc: headingselectors: "h1.toc1, h2.toc2, h3.toc3, h4.toc4, h5.toc5, h6.toc6" --- -The following is a reference for the JSON object definitions derived from the [metaschema](https://github.com/usnistgov/OSCAL/blob/develop//src/metaschema/oscal_poam_metaschema.xml) for this [model](/concepts/layer/assessment/poam/). +The following is a reference for the JSON object definitions derived from the [metaschema](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch//src/metaschema/oscal_poam_metaschema.xml) for this [model](/concepts/layer/assessment/poam/). {{< rawhtml >}} diff --git a/docs/content/reference/develop/plan-of-action-and-milestones/json-index.md b/docs/content/reference/develop/plan-of-action-and-milestones/json-index.md index ac3d53198f..fc94e25e5c 100644 --- a/docs/content/reference/develop/plan-of-action-and-milestones/json-index.md +++ b/docs/content/reference/develop/plan-of-action-and-milestones/json-index.md @@ -10,7 +10,7 @@ toc: headingselectors: "h1.toc1" --- -The following is an index of each JSON property used in the [JSON format](https://github.com/usnistgov/OSCAL/blob/develop/json/schema/oscal_poam_schema.json) for this [model](/concepts/layer/assessment/poam/). Each entry in the index lists all uses of the given property in the format, which is linked to the corresponding entry in the [JSON Format Reference](../json-reference/). Each entry also lists the formal name for the definition which is linked to the corresponding JSON definition in the [JSON Format Metaschema Reference](../json-definitions/). +The following is an index of each JSON property used in the [JSON format](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch/json/schema/oscal_poam_schema.json) for this [model](/concepts/layer/assessment/poam/). Each entry in the index lists all uses of the given property in the format, which is linked to the corresponding entry in the [JSON Format Reference](../json-reference/). Each entry also lists the formal name for the definition which is linked to the corresponding JSON definition in the [JSON Format Metaschema Reference](../json-definitions/). {{< rawhtml >}} diff --git a/docs/content/reference/develop/plan-of-action-and-milestones/json-outline.md b/docs/content/reference/develop/plan-of-action-and-milestones/json-outline.md index 389d6fb240..467735c234 100644 --- a/docs/content/reference/develop/plan-of-action-and-milestones/json-outline.md +++ b/docs/content/reference/develop/plan-of-action-and-milestones/json-outline.md @@ -10,7 +10,7 @@ sidenav: --- -The following outline is a representation of the [JSON format](https://github.com/usnistgov/OSCAL/blob/develop/json/schema/oscal_poam_schema.json) for this [model](/concepts/layer/assessment/poam/). For each property, the name links to the corresponding entry in the [JSON Format Reference](../json-reference/). The cardinality and data type are also provided for each property where appropriate. +The following outline is a representation of the [JSON format](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch/json/schema/oscal_poam_schema.json) for this [model](/concepts/layer/assessment/poam/). For each property, the name links to the corresponding entry in the [JSON Format Reference](../json-reference/). The cardinality and data type are also provided for each property where appropriate. {{< rawhtml >}} diff --git a/docs/content/reference/develop/plan-of-action-and-milestones/xml-definitions.md b/docs/content/reference/develop/plan-of-action-and-milestones/xml-definitions.md index 7a1db8dd80..48cc6bb70c 100644 --- a/docs/content/reference/develop/plan-of-action-and-milestones/xml-definitions.md +++ b/docs/content/reference/develop/plan-of-action-and-milestones/xml-definitions.md @@ -10,7 +10,7 @@ toc: headingselectors: "h1.toc1, h2.toc2, h3.toc3, h4.toc4, h5.toc5, h6.toc6" --- -The following is a reference for the XML element and attribute types derived from the [metaschema](https://github.com/usnistgov/OSCAL/blob/develop//src/metaschema/oscal_poam_metaschema.xml) for this [model](/concepts/layer/assessment/poam/). +The following is a reference for the XML element and attribute types derived from the [metaschema](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch//src/metaschema/oscal_poam_metaschema.xml) for this [model](/concepts/layer/assessment/poam/). {{< rawhtml >}}a string value
- - - -</telephone-number>
a string value
- - - -</telephone-number>
a uuid value
- - - - -</member-of-organization>
a string value
- - An inspection was performed. - An interview was performed. - A manual or automated test was performed. - This is only for use when converting historic content to OSCAL, where the conversion - process cannot initially identify the appropriate method(s). - -</method>
a token value
- - A difference between the SSP implementation statement, and actual implementation. - An observation about the status of a the associated control objective. - A mitigating factor was identified. - An assessment finding. Used for observations made by tools, penetration testing, and - other means. - An observation from a past assessment, which was converted to OSCAL at a later date. - -</type>
a token value
- - The risk has been identified. - The identified risk is being investigated. (Open risk) - Remediation activities are underway, but are not yet complete. (Open risk) - A risk deviation, such as false positive, risk reduction, or operational requirement - has been submitted for approval. (Open risk) - A risk deviation, such as false positive, risk reduction, or operational requirement - has been approved. (Open risk) - The risk has been resolved. - -</status>
a token value
- - The risk has been identified. - The identified risk is being investigated. (Open risk) - Remediation activities are underway, but are not yet complete. (Open risk) - A risk deviation, such as false positive, risk reduction, or operational requirement - has been submitted for approval. (Open risk) - A risk deviation, such as false positive, risk reduction, or operational requirement - has been approved. (Open risk) - The risk has been resolved. - -</status-change>
Release Version Latest Development Snapshot
-Github usnistgov/OSCAL Branch develop
+Github usnistgov/OSCAL Branch 1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch
The following reference documentation is available for the OSCAL Profile model. @@ -19,4 +19,4 @@ The following reference documentation is available for the OSCAL Profile model. - **Outline ([JSON/YAML](json-outline/), [XML](xml-outline/)):** Provides a brief listing of the model's information items organized hierarchically. Useful for understanding the structure and basic syntax of the model in a given format. - **Reference ([JSON/YAML](json-reference/), [XML](xml-reference/)):** Provides a detailed description of the structure and syntax for the model's information items organized hierarchically. Useful for understanding how to use information items within the model in the given format. - **Index ([JSON/YAML](json-index/), [XML](xml-index/)):** Provides a listing of the model's information items organized by where they are used. -- **Definitions ([JSON/YAML](json-definitions/), [XML](xml-definitions/)):** Provides a reference for the XML Schema types and JSON Schema definitions derived from this model's [metaschema](https://github.com/usnistgov/OSCAL/blob/develop/src/metaschema/oscal_profile). A metaschema is used to [express the model](/concepts/layer/overview/#modeling-approach) in a format agnostic way, that is then used to generate the XML and JSON Schema, XML <-> JSON content converters, and this reference documentation. +- **Definitions ([JSON/YAML](json-definitions/), [XML](xml-definitions/)):** Provides a reference for the XML Schema types and JSON Schema definitions derived from this model's [metaschema](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch/src/metaschema/oscal_profile). A metaschema is used to [express the model](/concepts/layer/overview/#modeling-approach) in a format agnostic way, that is then used to generate the XML and JSON Schema, XML <-> JSON content converters, and this reference documentation. diff --git a/docs/content/reference/develop/profile/json-definitions.md b/docs/content/reference/develop/profile/json-definitions.md index 29b3894275..2a70336633 100644 --- a/docs/content/reference/develop/profile/json-definitions.md +++ b/docs/content/reference/develop/profile/json-definitions.md @@ -10,7 +10,7 @@ toc: headingselectors: "h1.toc1, h2.toc2, h3.toc3, h4.toc4, h5.toc5, h6.toc6" --- -The following is a reference for the JSON object definitions derived from the [metaschema](https://github.com/usnistgov/OSCAL/blob/develop//src/metaschema/oscal_profile_metaschema.xml) for this [model](/concepts/layer/control/profile/). +The following is a reference for the JSON object definitions derived from the [metaschema](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch//src/metaschema/oscal_profile_metaschema.xml) for this [model](/concepts/layer/control/profile/). {{< rawhtml >}} @@ -1424,7 +1424,7 @@ The following is a reference for the JSON object definitions derived from the [m -assembly
Select Control
use name include-controls
group as include-controls
description Select a control or controls from an imported control set.
If with-child-controls
is yes
on the call to a control, no sibling call
elements need to be used to call any controls appearing within it. Since generally,
- this is how control enhancements are represented (as controls within controls), this
- provides a way to include controls with all their dependent controls (enhancements)
- without having to call them individually.
Identifies a subset of controls to import from the referenced catalog or profile by - control identifier or match pattern.
+If with-child-controls
is yes
on the call to a control, any controls appearing within it (child controls) will
+ be selected, with no additional call
directives required. This flag provides a way to include controls with all their
+ dependent controls (enhancements) without having to call them individually.
If with-parent-controls is "yes" on the call to a control, it will not be selected + and removed from (shown without) a parent control, but instead will be copied with + its parent in the source. This flag provides a way to include controls with all their + ancestor controls (enhancements) without having to call them individually.
[0 or 1]
+ +Include Contained Controls with Control
+group as with-ids
group as matching
description Selecting a set of controls by matching their IDs with a wildcard pattern.
+Match Controls by Identifier
assembly
Match Controls by Pattern
description Selecting a set of controls by matching their IDs with a wildcard pattern.
group as matching
description Selecting a control by its ID given as a literal.
+description When a control is included, whether its parent (ancestor) controls are also included.
+allowed values
+The value must be one of the following:
+An array of include-controls objects [1 to ∞] {
-with-child-controls [0 or 1]: token,
+with-parent-controls [0 or 1]: token,
+]
+}
If with-child-controls
is yes
on the call to a control, no sibling call
elements need to be used to call any controls appearing within it. Since generally,
- this is how control enhancements are represented (as controls within controls), this
- provides a way to include controls with all their dependent controls (enhancements)
- without having to call them individually.
Identifies a subset of controls to import from the referenced catalog or profile by - control identifier or match pattern.
+If with-child-controls
is yes
on the call to a control, any controls appearing within it (child controls) will
+ be selected, with no additional call
directives required. This flag provides a way to include controls with all their
+ dependent controls (enhancements) without having to call them individually.
If with-parent-controls is "yes" on the call to a control, it will not be selected + and removed from (shown without) a parent control, but instead will be copied with + its parent in the source. This flag provides a way to include controls with all their + ancestor controls (enhancements) without having to call them individually.
Description When a control is included, whether its parent (ancestor) controls are also included.
+allowed values
+The value must be one of the following:
+assembly
Select Control
use name include-controls
description Select a control or controls from an imported control set.
If with-child-controls
is yes
on the call to a control, no sibling call
elements need to be used to call any controls appearing within it. Since generally,
- this is how control enhancements are represented (as controls within controls), this
- provides a way to include controls with all their dependent controls (enhancements)
- without having to call them individually.
Identifies a subset of controls to import from the referenced catalog or profile by - control identifier or match pattern.
+If with-child-controls
is yes
on the call to a control, any controls appearing within it (child controls) will
+ be selected, with no additional call
directives required. This flag provides a way to include controls with all their
+ dependent controls (enhancements) without having to call them individually.
If with-parent-controls is "yes" on the call to a control, it will not be selected + and removed from (shown without) a parent control, but instead will be copied with + its parent in the source. This flag provides a way to include controls with all their + ancestor controls (enhancements) without having to call them individually.
[0 or 1]
+ +Include Contained Controls with Control
+description Selecting a set of controls by matching their IDs with a wildcard pattern.
+Match Controls by Identifier
description Selecting a control by its ID given as a literal.
+assembly
Match Controls by Pattern
description Selecting a set of controls by matching their IDs with a wildcard pattern.
-description Selecting a control by its ID given as a literal.
+description When a control is included, whether its parent (ancestor) controls are also included.
+allowed values
+The value must be one of the following:
+a string value
- - - -</telephone-number>
a string value
- - - -</telephone-number>
a uuid value
- - - - -</member-of-organization>
If with-child-controls
is yes
on the call to a control, no sibling call
elements need to be used to call any controls appearing within it. Since generally,
- this is how control enhancements are represented (as controls within controls), this
- provides a way to include controls with all their dependent controls (enhancements)
- without having to call them individually.
Identifies a subset of controls to import from the referenced catalog or profile by - control identifier or match pattern.
+If with-child-controls
is yes
on the call to a control, any controls appearing within it (child controls) will
+ be selected, with no additional call
directives required. This flag provides a way to include controls with all their
+ dependent controls (enhancements) without having to call them individually.
If with-parent-controls is "yes" on the call to a control, it will not be selected + and removed from (shown without) a parent control, but instead will be copied with + its parent in the source. This flag provides a way to include controls with all their + ancestor controls (enhancements) without having to call them individually.
Description When a control is included, whether its parent (ancestor) controls are also included.
+allowed values
+The value must be one of the following:
+Release Version Latest Development Snapshot
-Github usnistgov/OSCAL Branch develop
+Github usnistgov/OSCAL Branch 1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch
The following reference documentation is available for the OSCAL System Security Plan model. @@ -19,4 +19,4 @@ The following reference documentation is available for the OSCAL System Security - **Outline ([JSON/YAML](json-outline/), [XML](xml-outline/)):** Provides a brief listing of the model's information items organized hierarchically. Useful for understanding the structure and basic syntax of the model in a given format. - **Reference ([JSON/YAML](json-reference/), [XML](xml-reference/)):** Provides a detailed description of the structure and syntax for the model's information items organized hierarchically. Useful for understanding how to use information items within the model in the given format. - **Index ([JSON/YAML](json-index/), [XML](xml-index/)):** Provides a listing of the model's information items organized by where they are used. -- **Definitions ([JSON/YAML](json-definitions/), [XML](xml-definitions/)):** Provides a reference for the XML Schema types and JSON Schema definitions derived from this model's [metaschema](https://github.com/usnistgov/OSCAL/blob/develop/src/metaschema/oscal_ssp). A metaschema is used to [express the model](/concepts/layer/overview/#modeling-approach) in a format agnostic way, that is then used to generate the XML and JSON Schema, XML <-> JSON content converters, and this reference documentation. +- **Definitions ([JSON/YAML](json-definitions/), [XML](xml-definitions/)):** Provides a reference for the XML Schema types and JSON Schema definitions derived from this model's [metaschema](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch/src/metaschema/oscal_ssp). A metaschema is used to [express the model](/concepts/layer/overview/#modeling-approach) in a format agnostic way, that is then used to generate the XML and JSON Schema, XML <-> JSON content converters, and this reference documentation. diff --git a/docs/content/reference/develop/system-security-plan/json-definitions.md b/docs/content/reference/develop/system-security-plan/json-definitions.md index 9affe2e8b3..3e00788f10 100644 --- a/docs/content/reference/develop/system-security-plan/json-definitions.md +++ b/docs/content/reference/develop/system-security-plan/json-definitions.md @@ -10,7 +10,7 @@ toc: headingselectors: "h1.toc1, h2.toc2, h3.toc3, h4.toc4, h5.toc5, h6.toc6" --- -The following is a reference for the JSON object definitions derived from the [metaschema](https://github.com/usnistgov/OSCAL/blob/develop//src/metaschema/oscal_ssp_metaschema.xml) for this [model](/concepts/layer/implementation/ssp/). +The following is a reference for the JSON object definitions derived from the [metaschema](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch//src/metaschema/oscal_ssp_metaschema.xml) for this [model](/concepts/layer/implementation/ssp/). {{< rawhtml >}} @@ -2911,7 +2911,7 @@ The following is a reference for the JSON object definitions derived from the [mallowed value for (.|statement|.//by-component)/prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal')]/@name
allowed value for prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal')]/@name
The value must be one of the following:
-allowed values for responsible-role/@role-id
The value may be locally defined, or one of the following:
diff --git a/docs/content/reference/develop/system-security-plan/json-index.md b/docs/content/reference/develop/system-security-plan/json-index.md index c38a93e3a3..d73671a797 100644 --- a/docs/content/reference/develop/system-security-plan/json-index.md +++ b/docs/content/reference/develop/system-security-plan/json-index.md @@ -10,7 +10,7 @@ toc: headingselectors: "h1.toc1" --- -The following is an index of each JSON property used in the [JSON format](https://github.com/usnistgov/OSCAL/blob/develop/json/schema/oscal_ssp_schema.json) for this [model](/concepts/layer/implementation/ssp/). Each entry in the index lists all uses of the given property in the format, which is linked to the corresponding entry in the [JSON Format Reference](../json-reference/). Each entry also lists the formal name for the definition which is linked to the corresponding JSON definition in the [JSON Format Metaschema Reference](../json-definitions/). +The following is an index of each JSON property used in the [JSON format](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch/json/schema/oscal_ssp_schema.json) for this [model](/concepts/layer/implementation/ssp/). Each entry in the index lists all uses of the given property in the format, which is linked to the corresponding entry in the [JSON Format Reference](../json-reference/). Each entry also lists the formal name for the definition which is linked to the corresponding JSON definition in the [JSON Format Metaschema Reference](../json-definitions/). {{< rawhtml >}} diff --git a/docs/content/reference/develop/system-security-plan/json-outline.md b/docs/content/reference/develop/system-security-plan/json-outline.md index cf0ee27762..b0d85de004 100644 --- a/docs/content/reference/develop/system-security-plan/json-outline.md +++ b/docs/content/reference/develop/system-security-plan/json-outline.md @@ -10,7 +10,7 @@ sidenav: --- -The following outline is a representation of the [JSON format](https://github.com/usnistgov/OSCAL/blob/develop/json/schema/oscal_ssp_schema.json) for this [model](/concepts/layer/implementation/ssp/). For each property, the name links to the corresponding entry in the [JSON Format Reference](../json-reference/). The cardinality and data type are also provided for each property where appropriate. +The following outline is a representation of the [JSON format](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch/json/schema/oscal_ssp_schema.json) for this [model](/concepts/layer/implementation/ssp/). For each property, the name links to the corresponding entry in the [JSON Format Reference](../json-reference/). The cardinality and data type are also provided for each property where appropriate. {{< rawhtml >}} diff --git a/docs/content/reference/develop/system-security-plan/json-reference.md b/docs/content/reference/develop/system-security-plan/json-reference.md index 3f29dafc2d..bf135f3283 100644 --- a/docs/content/reference/develop/system-security-plan/json-reference.md +++ b/docs/content/reference/develop/system-security-plan/json-reference.md @@ -15263,7 +15263,7 @@ The following is the JSON format reference for this [model](/concepts/layer/implallowed value for (.|statement|.//by-component)/prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal')]/@name
The value must be one of the following:
@@ -15291,15 +15291,6 @@ The following is the JSON format reference for this [model](/concepts/layer/implallowed value for prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal')]/@name
The value must be one of the following:
-allowed values for responsible-role/@role-id
The value may be locally defined, or one of the following:
diff --git a/docs/content/reference/develop/system-security-plan/xml-definitions.md b/docs/content/reference/develop/system-security-plan/xml-definitions.md index 46382bf06e..c0620902e2 100644 --- a/docs/content/reference/develop/system-security-plan/xml-definitions.md +++ b/docs/content/reference/develop/system-security-plan/xml-definitions.md @@ -10,7 +10,7 @@ toc: headingselectors: "h1.toc1, h2.toc2, h3.toc3, h4.toc4, h5.toc5, h6.toc6" --- -The following is a reference for the XML element and attribute types derived from the [metaschema](https://github.com/usnistgov/OSCAL/blob/develop//src/metaschema/oscal_ssp_metaschema.xml) for this [model](/concepts/layer/implementation/ssp/). +The following is a reference for the XML element and attribute types derived from the [metaschema](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch//src/metaschema/oscal_ssp_metaschema.xml) for this [model](/concepts/layer/implementation/ssp/). {{< rawhtml >}}allowed value for (.|statement|.//by-component)/prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal')]/@name
allowed value for prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal')]/@name
The value must be one of the following:
-allowed values for responsible-role/@role-id
The value may be locally defined, or one of the following:
diff --git a/docs/content/reference/develop/system-security-plan/xml-index.md b/docs/content/reference/develop/system-security-plan/xml-index.md index c8d0f687ac..31c39ba1e4 100644 --- a/docs/content/reference/develop/system-security-plan/xml-index.md +++ b/docs/content/reference/develop/system-security-plan/xml-index.md @@ -10,7 +10,7 @@ toc: headingselectors: "h1.toc1" --- -The following is an index of each XML element and attribute used in the [XML format](https://github.com/usnistgov/OSCAL/blob/develop/xml/schema/oscal_ssp_schema.xsd) for this [model](/concepts/layer/implementation/ssp/). Each entry in the index lists all uses of the given element or attribute in the format, which is linked to the corresponding entry in the [XML Format Reference](../xml-reference/). Each entry also lists the formal name for the given element or attribute which is linked to the corresponding XML type in the [XML Format Metaschema Reference](../xml-definitions/). +The following is an index of each XML element and attribute used in the [XML format](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch/xml/schema/oscal_ssp_schema.xsd) for this [model](/concepts/layer/implementation/ssp/). Each entry in the index lists all uses of the given element or attribute in the format, which is linked to the corresponding entry in the [XML Format Reference](../xml-reference/). Each entry also lists the formal name for the given element or attribute which is linked to the corresponding XML type in the [XML Format Metaschema Reference](../xml-definitions/). {{< rawhtml >}} diff --git a/docs/content/reference/develop/system-security-plan/xml-outline.md b/docs/content/reference/develop/system-security-plan/xml-outline.md index dc40e176d0..e082059005 100644 --- a/docs/content/reference/develop/system-security-plan/xml-outline.md +++ b/docs/content/reference/develop/system-security-plan/xml-outline.md @@ -10,7 +10,7 @@ sidenav: --- -The following outline is a representation of the [XML format](https://github.com/usnistgov/OSCAL/blob/develop/xml/schema/oscal_ssp_schema.xsd) for this [model](/concepts/layer/implementation/ssp/). For each element or attribute, the name links to the corresponding entry in the [XML Format Reference](../xml-reference/). The cardinality and data type are also provided for each element or attribute where appropriate. +The following outline is a representation of the [XML format](https://github.com/usnistgov/OSCAL/blob/1703-date-regex-not-updated-to-fixed-v104-version-in-json-schema-or-in-main-branch/xml/schema/oscal_ssp_schema.xsd) for this [model](/concepts/layer/implementation/ssp/). For each element or attribute, the name links to the corresponding entry in the [XML Format Reference](../xml-reference/). The cardinality and data type are also provided for each element or attribute where appropriate. {{< rawhtml >}}a string value
- - - -</telephone-number>
a string value
- - - -</telephone-number>
a uuid value
- - - - -</member-of-organization>
allowed value for (.|statement|.//by-component)/prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal')]/@name
The value must be one of the following:
@@ -15971,15 +15971,6 @@ The following is the XML format reference for this [model](/concepts/layer/impleallowed value for prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal')]/@name
The value must be one of the following:
-allowed values for responsible-role/@role-id
The value may be locally defined, or one of the following:
diff --git a/json/convert/oscal_assessment-plan_xml-to-json-converter.xsl b/json/convert/oscal_assessment-plan_xml-to-json-converter.xsl index 4f0569809f..d6414877b8 100644 --- a/json/convert/oscal_assessment-plan_xml-to-json-converter.xsl +++ b/json/convert/oscal_assessment-plan_xml-to-json-converter.xsl @@ -5268,14 +5268,12 @@