{ $href }{ @href }{ document-uri(/) => replace('.*/','') }{ $resultpath }{ name() }
+{ name() }
+
+
with-id { . }
+set-parameter { @param-id }
+alter { @control-id }
+{ local-name() } { @id }
+{ local-name() } { @id }
+resource { @uuid }
+insert { @type } { @id-ref }
+combine { @method }
+{ local-name() } { . }
+{ local-name() } { . }
+rlink { @href }
+title
{ local-name(.) } { @name } { @id } { [1 to count(child::*) ] ! '▮' }
+{ local-name(.) } { @name }{ @value }
+{ local-name() } { (1 to count(child::*)) ! '▮' }
+with child controls { . }
+{ replace(local-name(.),'\-',' ') } { . }
+
+
+
+
+
+ { current-grouping-key() }
+
+ { current-grouping-key() }
+
A1 aaaaa aaaaaaaaaa
+Parameter A.a is set:
+
Parameter a1.a is set:
+
A1 aaaaa aaaaaaaaaa
+Parameter A.a is set:
+
Parameter a1.a is set:
profilebase-test_profile.xmlbase2-test_profile.xmlbroken_profile.xmlcircular_profile.xmlexclude-call-test_profile.xmlfull-test_profile.xmlhome_profile.xmlimport-twice_profile.xmlinclude-all-no-children-test_profile.xmlinclude-all-test_profile.xmlinclude-call-with-children-test_profile.xmlinclude-loose-param-test_profile.xmlinclude-match-test_profile.xmlmerge-implicit-keep_profile.xmlmerge-keep-resources_profile.xmlmerge-keep_profile.xmlmodify-adds_profile.xml
+metadatabase-test_profile.xmlbase2-test_profile.xmlbroken_profile.xmlcircular_profile.xmlexclude-call-test_profile.xmlfull-test_profile.xmlhome_profile.xmlimport-twice_profile.xmlinclude-all-no-children-test_profile.xmlinclude-all-test_profile.xmlinclude-call-with-children-test_profile.xmlinclude-loose-param-test_profile.xmlinclude-match-test_profile.xmlmerge-implicit-keep_profile.xmlmerge-keep-resources_profile.xmlmerge-keep_profile.xmlmodify-adds_profile.xml
+titlebase-test_profile.xmlbase2-test_profile.xmlbroken_profile.xmlcircular_profile.xmlexclude-call-test_profile.xmlfull-test_profile.xmlhome_profile.xmlimport-twice_profile.xmlinclude-all-no-children-test_profile.xmlinclude-all-test_profile.xmlinclude-call-with-children-test_profile.xmlinclude-loose-param-test_profile.xmlinclude-match-test_profile.xmlmerge-implicit-keep_profile.xmlmerge-keep-resources_profile.xmlmerge-keep_profile.xmlmodify-adds_profile.xml
+last-modifiedbase-test_profile.xmlbase2-test_profile.xmlbroken_profile.xmlcircular_profile.xmlexclude-call-test_profile.xmlfull-test_profile.xmlhome_profile.xmlimport-twice_profile.xmlinclude-all-no-children-test_profile.xmlinclude-all-test_profile.xmlinclude-call-with-children-test_profile.xmlinclude-loose-param-test_profile.xmlinclude-match-test_profile.xmlmerge-implicit-keep_profile.xmlmerge-keep-resources_profile.xmlmerge-keep_profile.xmlmodify-adds_profile.xml
+versionbase-test_profile.xmlbase2-test_profile.xmlbroken_profile.xmlcircular_profile.xmlexclude-call-test_profile.xmlfull-test_profile.xmlhome_profile.xmlimport-twice_profile.xmlinclude-all-no-children-test_profile.xmlinclude-all-test_profile.xmlinclude-call-with-children-test_profile.xmlinclude-loose-param-test_profile.xmlinclude-match-test_profile.xmlmerge-implicit-keep_profile.xmlmerge-keep-resources_profile.xmlmerge-keep_profile.xmlmodify-adds_profile.xml
+oscal-versionbase-test_profile.xmlbase2-test_profile.xmlbroken_profile.xmlcircular_profile.xmlexclude-call-test_profile.xmlfull-test_profile.xmlhome_profile.xmlimport-twice_profile.xmlinclude-all-no-children-test_profile.xmlinclude-all-test_profile.xmlinclude-call-with-children-test_profile.xmlinclude-loose-param-test_profile.xmlinclude-match-test_profile.xmlmerge-implicit-keep_profile.xmlmerge-keep-resources_profile.xmlmerge-keep_profile.xmlmodify-adds_profile.xml
+importbase-test_profile.xmlbase2-test_profile.xmlbroken_profile.xmlcircular_profile.xmlexclude-call-test_profile.xmlfull-test_profile.xmlhome_profile.xmlimport-twice_profile.xmlinclude-all-no-children-test_profile.xmlinclude-all-test_profile.xmlinclude-call-with-children-test_profile.xmlinclude-loose-param-test_profile.xmlinclude-match-test_profile.xmlmerge-implicit-keep_profile.xmlmerge-keep-resources_profile.xmlmerge-keep_profile.xmlmodify-adds_profile.xml
+catalogs/abc-simple_catalog.xmlbase-test_profile.xmlexclude-call-test_profile.xmlinclude-call-with-children-test_profile.xmlinclude-match-test_profile.xml
+#0050231f-4fd0-43d6-8fa0-431367cd83e1base2-test_profile.xml
+missing_profile.xmlbroken_profile.xml
+home_profile.xmlcircular_profile.xml
+catalogs/abc-full_catalog.xmlfull-test_profile.xmlinclude-all-no-children-test_profile.xmlinclude-all-test_profile.xmlinclude-loose-param-test_profile.xml
+circular_profile.xmlhome_profile.xml
+#7c688dca-f0dc-4d09-b6f0-f562165ad7d9import-twice_profile.xml
+#9c745ccc-6a85-4172-a752-11c786910e3cmerge-implicit-keep_profile.xml
+#01ecd6cc-e281-472c-bb7a-0394bdf938f2merge-keep-resources_profile.xml
+#a097e626-2606-4213-8ae0-390e3d3d2aaamerge-keep_profile.xml
+#4d263315-ebac-45cc-801e-f5a986cd59a9modify-adds_profile.xml
+include-controlsbase-test_profile.xmlbase2-test_profile.xmlbroken_profile.xmlcircular_profile.xmlfull-test_profile.xmlhome_profile.xmlimport-twice_profile.xmlinclude-call-with-children-test_profile.xmlinclude-loose-param-test_profile.xmlinclude-match-test_profile.xmlmerge-implicit-keep_profile.xmlmerge-keep-resources_profile.xmlmerge-keep_profile.xmlmodify-adds_profile.xml
+with-idbase-test_profile.xmlbase2-test_profile.xmlbroken_profile.xmlcircular_profile.xmlfull-test_profile.xmlhome_profile.xmlimport-twice_profile.xmlinclude-call-with-children-test_profile.xmlinclude-loose-param-test_profile.xmlmerge-implicit-keep_profile.xmlmerge-keep-resources_profile.xmlmerge-keep_profile.xmlmodify-adds_profile.xml
+matchinginclude-match-test_profile.xml
+include-allexclude-call-test_profile.xmlinclude-all-no-children-test_profile.xmlinclude-all-test_profile.xml
+exclude-controlsexclude-call-test_profile.xml
+back-matterbase2-test_profile.xmlimport-twice_profile.xmlmerge-implicit-keep_profile.xmlmerge-keep-resources_profile.xmlmerge-keep_profile.xmlmodify-adds_profile.xml
+resourcebase2-test_profile.xmlimport-twice_profile.xmlmerge-implicit-keep_profile.xmlmerge-keep-resources_profile.xmlmerge-keep_profile.xmlmodify-adds_profile.xml
+rlinkbase2-test_profile.xmlimport-twice_profile.xmlmerge-implicit-keep_profile.xmlmerge-keep-resources_profile.xmlmerge-keep_profile.xmlmodify-adds_profile.xml
+catalogs/abc-simple_catalog.xmlbase2-test_profile.xmlimport-twice_profile.xmlmerge-implicit-keep_profile.xmlmerge-keep-resources_profile.xmlmerge-keep_profile.xmlmodify-adds_profile.xml
+https://csrc.nist.gov/publications/detail/sp/800-37/rev-2/finalmerge-keep-resources_profile.xml
+document-idmerge-keep-resources_profile.xml
+https://www.doi.org/merge-keep-resources_profile.xml
+mergemerge-keep_profile.xmlmodify-adds_profile.xml
+combinemerge-keep_profile.xmlmodify-adds_profile.xml
+modifymodify-adds_profile.xml
+set-parametermodify-adds_profile.xml
+a1_prm1modify-adds_profile.xml
+a3_prm1modify-adds_profile.xml
+constraintmodify-adds_profile.xml
+descriptionmodify-adds_profile.xml
+ +startingmodify-adds_profile.xml
+a1-stmtmodify-adds_profile.xml
+https://fedramp.gov/ns/oscalmodify-adds_profile.xml
+assessment-objectivemodify-adds_profile.xml
+EXAMINEmodify-adds_profile.xml
+fedrampmodify-adds_profile.xml
+A1 aaaaa aaaaaaaaaa
+Parameter A.a is set:
Parameter a1.a is set:
A1 aaaaa aaaaaaaaaa
+Parameter A.a is set:
Parameter a1.a is set:
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:.
+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
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. 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.
+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
YAML maps cleanly to JSON, thus allowing easy use of existing JSON/XML transformers where needed. With that in mind, the OSCAL Complete JSON Reference is 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 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 - listitemkey:value.
The YAML specification is freely available here:YAML 1.2.
+Additionally, in order to unambiguously express information, this specification uses additional conventions, as described below.
+There are some objects whose values must be determined dynamically at processing time. The most common example of this is timestamping output as it is processed. In this case, and any other dynamic-value cases, the expression ${{ }} is used.
For example:
+Indicates the
Some examples may elide content to enhance readability or save space. In these cases, a YAML comment (any line that starts with #) 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 (
The specification is broken into the following major sections:
+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.
+The three steps are
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:
+In an import directive, the reference to the resource to be imported appears on an
An external reference appears as an absolute or relative URL:
+While an internal reference appears as below (see
All import directives will contain either
The following section contains requirements for processing the
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".
+A
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.
+A profile identified as home_profile.yaml imports another one identified as circular_profile.yaml:
In turn this file invokes home_profile.xml:
Once detected, this circular import will result in an error and no further processing will take place.
+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
The control inclusions are combined and collapsed in the next phase of processing,
Multiple imports against the same resource are allowed, and would most commonly occur when the profile author is using
The optional
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
MUST update all known references to the old ID in other included content, allowing the new ID to be used in subsequent profile sections.
+Since mapping is a self contained process inside each import, the rest of this specification will continue to reference IDs with the assumption that mapping has already been applied if it was present. Since mapping is most commonly used to avoid clashing IDs, processors should take care to not handle duplicate IDs until after mapping is complete.
+Below is a simple example of mapping. The second
Using the intermediate approach, an internal data structure resembling the following would result from the above profile:
+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.
+id match one of the listed id values MUST be included.
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.
+id matches one of the listed pattern values (Glob matching) MUST be included.
matching object is provided with no pattern, it MUST be treated as matching nothing. While not providing a pattern is technically valid, resolution tool implementers should be aware that it is generally undesirable, and warnings or notices to the user may be appropriate.
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
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.
+Although similar to the above
Exclusions work the same way as inclusions, except with the opposite effect - the indicated control(s) do not appear in the target catalog.
+ac-1 and excluded by matching ac.*, it is excluded.
Note that this requirement only applies to controls included within the context of a single import. Controls with duplicate IDs included under a different
Any loose
param.
Some source catalogs use
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
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
Profiles may contain a merge has two parts: a "combine" directive, and a "structuring" directive.
The following section contains requirements for processing the
combine is an optional child of merge that provides the rules for dealing with objects that have duplicate (or clashing) distinct IDs
There are two valid combination methods provided by OSCAL, provided by the
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
+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.
+is the same as
+method:keep+
keep
combination rule is used. Any controls with the same distinctive ID
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.
+In the intermediate (showing control inclusions):
+In this case, downstream errors should be expected: the two ac-1 controls clash with each other, as do the two ac-2 controls.
method:use-first+
use-first
combination rule is applied, and controls that share a distinctive ID are found, the first control encountered MUST be kept, the rest MUST be discarded.First
MUST be determined by a top-down, depth-first traversal of the source profile's import hierarchy.
In the intermediate(showing control inclusions):
+Deprecated, unspecified behavior.
+This section describes how a profile may dictate the structure of the target
is the same as
+An example of flat structuring is provided below
+as-is+
An
Example:
+custom+
The
Note that groups defined in
The
In order to provide clarity, controls that match the various conditions of these inclusion directives inside the
A
A
An
ascending will sort all selected controls into ascending alphanumeric order by their ID.
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.
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
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
Modification of parameter settings is indicated using the
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".
A control can be altered by 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.
+starting, or at the end if its position is ending, or if no valid poisition is given.
before and after MUST be treated like starting and ending, respectively.
Control contents in catalogs must appear in the order title, param, prop, link, part, control per the OSCAL model documentation.ending, or not given, or before any starting.
An addition operating on a control with implicit binding and position starting
Position is starting but the new
An addition operating on a control with implicit binding and position ending
The ending so the new
An explicit binding on an addition permits inserting new contents anywhere in a control, not only at the top level.
The object with
starting or ending, the contents of the source MUST be added inside the target, either at the start or end of its contents, respectively.
before or after, the contents of the source MUST be added outside the target, either directly before or after it, respectively.
An addition operating on a control with explicit binding and position after
Note that the a1.b1 as its target.
The after so both objects inside
Note that the result in this case will be schema-invalid since a
OSCAL supports controls inside controls in the form of
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:item-name:prop has the effect of removing all
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:
+{{sourceprofilename}}-RESOLVED-{{GUIDv5}}).
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
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.
+Whenever this specification refers to distinctiveness
, it is to be interpreted as is defined in this section with regards to the object in question.
id
child object.
uuid
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 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
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
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
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.
-The three steps are
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.
A
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.
-A profile identified as
- home_profile.yamlimports another one identified as
- circular_profile.yaml:
-
A profile identified as home_profile.yamlimports another one identified as
+ circular_profile.yaml:
In turn this file invokes
- home_profile.xml:
-
In turn this file invokes home_profile.xml:
Once detected, this circular import will result in an error and no further processing will take place.
+Once detected, this circular import will result in an error and no further processing + will take place.
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.
The control inclusions are combined and collapsed in the next phase of processing,
-
Multiple imports against the same resource are allowed, and would most commonly occur when the profile author is using
id match one of the listed
- id values MUST be included.
-
id match one of the listed id
+ values MUST be included.
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.
-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 id matches one of the listed
pattern values (Glob matching) MUST be included.
matching object is provided with no
pattern, it MUST be treated as matching nothing. While not providing a pattern is technically valid, resolution tool implementers should be aware that it is generally undesirable, and warnings or notices to the user may be appropriate.
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.
Exclusions work the same way as inclusions, except with the opposite effect - the indicated control(s) do not appear in the target catalog.
-ac-1 and excluded by matching
- ac.*, it is excluded.
-
ac-1 and excluded by matching ac*, it is excluded.
Note that this requirement only applies to controls included within the context of a single import. Controls with duplicate IDs included under a different
The following section contains requirements for processing the
keep: Keep - controls with the same ID are kept, retaining the clash
-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.
A1 aaaaa aaaaaaaaaa Parameter A.a is set: Parameter a1.a is set: A2 aaa aaaaaaaaaa aaaaaaaaaaaaa Parameter A.b is set: A3 aaaaa aaaaaaaaaa B1 bbbb bbbbbbb. B2 bbb bbbbbbbbbbb bbbbbbbbbbbb. Also, we refer to a citation. B3 bbbb bbbbbbb bbbb. C1 ccccc ccc ccccccccccccccccc. We cite a document with an anchor: ... citation .... C2 cccccccc ccccccccccccccccc. C3 ccccc cccccccccccccc. C3 A ccccc cccccccccccccc. C3 A-1 ccccc cccccccccccccc. B2 bbb bbbbbbbbbbb bbbbbbbbbbbb. B1 bbbb bbbbbbb. B3 bbbb bbbbbbb bbbb. A3 aaaaa aaaaaaaaaa A2 aaa aaaaaaaaaa aaaaaaaaaaaaa A1 aaaaa aaaaaaaaaa C3 ccccc cccccccccccccc. C3 A ccccc cccccccccccccc. C3 A-1 ccccc cccccccccccccc. C1 ccccc ccc ccccccccccccccccc. C2 cccccccc ccccccccccccccccc. A1 aaaaa aaaaaaaaaa A2 aaa aaaaaaaaaa aaaaaaaaaaaaa A3 aaaaa aaaaaaaaaa B1 bbbb bbbbbbb. B2 bbb bbbbbbbbbbb bbbbbbbbbbbb. B3 bbbb bbbbbbb bbbb. C1 ccccc ccc ccccccccccccccccc. C2 cccccccc ccccccccccccccccc. C3 ccccc cccccccccccccc. C3 A ccccc cccccccccccccc. C3 A-1 ccccc cccccccccccccc. When referenced from anywhere, this should float through. C3 ccccc cccccccccccccc. C3 A ccccc cccccccccccccc. Making reference to a parameter in another control, like this: C1 ccccc ccc ccccccccccccccccc. If Control C2 is missing, should be floating free. C2 cccccccc ccccccccccccccccc. catalog group title Group B of C control b2 title Control B2 part statementb2-stmt ▮ control b1 title Control B1 part statementb1-stmt ▮ control b3 title Control B3 part statementb3-stmt ▮ group title Group A of C control a3 title Control A3 param a3_prm1 label A3 Parameter 1 part statementa3-stmt ▮ control a2 title Control A2 part statementa2-stmt ▮ control a1 title Control A1 param a1_prm1 label A1 Parameter 1 part statementa1-stmt ▮ group title Group C of C control c3 title Control C3 part statementc3-stmt ▮ control c3.a title Control C3-A part statementc3-stmt ▮ control c3.a-1 title Control C3-A-1 part statementc3-stmt ▮ control c1 title Control C1 part statementc1-stmt ▮ control c2 title Control C2 part statementc2-stmt ▮ profile importcatalogs/abc-mixed-up_catalog.xml include-all merge as-is true catalog group title Group B of C control b2 title Control B2 part statementb2-stmt ▮ control b1 title Control B1 part statementb1-stmt ▮ control b3 title Control B3 part statementb3-stmt ▮ group title Group A of C control a3 title Control A3 param a3_prm1 label A3 Parameter 1 part statementa3-stmt ▮ control a2 title Control A2 part statementa2-stmt ▮ control a1 title Control A1 param a1_prm1 label A1 Parameter 1 part statementa1-stmt ▮ group title Group C of C control c3 title Control C3 part statementc3-stmt ▮ control c3.a title Control C3-A part statementc3-stmt ▮ control c3.a-1 title Control C3-A-1 part statementc3-stmt ▮ control c1 title Control C1 part statementc1-stmt ▮ control c2 title Control C2 part statementc2-stmt ▮ catalog group title Group A of C control a1 title Control A1 param a1_prm1 label A1 Parameter 1 part statementa1-stmt ▮ control a2 title Control A2 part statementa2-stmt ▮ control a3 title Control A3 param a3_prm1 label A3 Parameter 1 part statementa3-stmt ▮ group title Group B of C control b1 title Control B1 part statementb1-stmt ▮ control b2 title Control B2 part statementb2-stmt ▮ control b3 title Control B3 part statementb3-stmt ▮ group title Group C of C control c1 title Control C1 part statementc1-stmt ▮ control c2 title Control C2 part statementc2-stmt ▮ control c3 title Control C3 part statementc3-stmt ▮ control c3.a title Control C3-A part statementc3-stmt ▮ control c3.a-1 title Control C3-A-1 part statementc3-stmt ▮ profile importcatalogs/abc-simple_catalog.xml include-controls with child controls yes with-id a1 with-id b1 with-id c1 with-id c3 catalog control a1 title Control A1 param a1_prm1 label A1 Parameter 1 part statementa1-stmt ▮ control b1 title Control B1 part statementb1-stmt ▮ control c1 title Control C1 part statementc1-stmt ▮ control c3 title Control C3 part statementc3-stmt ▮ control c3.a title Control C3-A part statementc3-stmt ▮ control c3.a-1 title Control C3-A-1 part statementc3-stmt ▮ B2 bbb bbbbbbbbbbb bbbbbbbbbbbb. B1 bbbb bbbbbbb. B3 bbbb bbbbbbb bbbb. A3 aaaaa aaaaaaaaaa A2 aaa aaaaaaaaaa aaaaaaaaaaaaa A1 aaaaa aaaaaaaaaa C3 ccccc cccccccccccccc. C3 A ccccc cccccccccccccc. C3 A-1 ccccc cccccccccccccc. C1 ccccc ccc ccccccccccccccccc. C2 cccccccc ccccccccccccccccc. B2 bbb bbbbbbbbbbb bbbbbbbbbbbb. B1 bbbb bbbbbbb. B3 bbbb bbbbbbb bbbb. A3 aaaaa aaaaaaaaaa A2 aaa aaaaaaaaaa aaaaaaaaaaaaa A1 aaaaa aaaaaaaaaa C3 ccccc cccccccccccccc. C3 A ccccc cccccccccccccc. C3 A-1 ccccc cccccccccccccc. C1 ccccc ccc ccccccccccccccccc. C2 cccccccc ccccccccccccccccc. B2 bbb bbbbbbbbbbb bbbbbbbbbbbb. B1 bbbb bbbbbbb. B3 bbbb bbbbbbb bbbb. A3 aaaaa aaaaaaaaaa A2 aaa aaaaaaaaaa aaaaaaaaaaaaa A1 aaaaa aaaaaaaaaa C3 ccccc cccccccccccccc. C3 A ccccc cccccccccccccc. C3 A-1 ccccc cccccccccccccc. C1 ccccc ccc ccccccccccccccccc. C2 cccccccc ccccccccccccccccc. B2 bbb bbbbbbbbbbb bbbbbbbbbbbb. B1 bbbb bbbbbbb. B3 bbbb bbbbbbb bbbb. A3 aaaaa aaaaaaaaaa A2 aaa aaaaaaaaaa aaaaaaaaaaaaa A1 aaaaa aaaaaaaaaa C3 ccccc cccccccccccccc. C3 A ccccc cccccccccccccc. C3 A-1 ccccc cccccccccccccc. C1 ccccc ccc ccccccccccccccccc. C2 cccccccc ccccccccccccccccc. B2 bbb bbbbbbbbbbb bbbbbbbbbbbb. B1 bbbb bbbbbbb. B3 bbbb bbbbbbb bbbb. A3 aaaaa aaaaaaaaaa A2 aaa aaaaaaaaaa aaaaaaaaaaaaa A1 aaaaa aaaaaaaaaa C3 ccccc cccccccccccccc. C3 A ccccc cccccccccccccc. C3 A-1 ccccc cccccccccccccc. C1 ccccc ccc ccccccccccccccccc. C2 cccccccc ccccccccccccccccc. B1 bbbb bbbbbbb. B3 bbbb bbbbbbb bbbb. A3 aaaaa aaaaaaaaaa A1 aaaaa aaaaaaaaaa C3 ccccc cccccccccccccc. C3 A ccccc cccccccccccccc. C3 A-1 ccccc cccccccccccccc. C1 ccccc ccc ccccccccccccccccc. B2 bbb bbbbbbbbbbb bbbbbbbbbbbb. B1 bbbb bbbbbbb. B3 bbbb bbbbbbb bbbb. A3 aaaaa aaaaaaaaaa A2 aaa aaaaaaaaaa aaaaaaaaaaaaa A1 aaaaa aaaaaaaaaa C3 ccccc cccccccccccccc. C3 A ccccc cccccccccccccc. C3 A-1 ccccc cccccccccccccc. C1 ccccc ccc ccccccccccccccccc. C2 cccccccc ccccccccccccccccc. B2 bbb bbbbbbbbbbb bbbbbbbbbbbb. B1 bbbb bbbbbbb. B3 bbbb bbbbbbb bbbb. A3 aaaaa aaaaaaaaaa A2 aaa aaaaaaaaaa aaaaaaaaaaaaa A1 aaaaa aaaaaaaaaa C3 ccccc cccccccccccccc. C3 A ccccc cccccccccccccc. C3 A-1 ccccc cccccccccccccc. C1 ccccc ccc ccccccccccccccccc. C2 cccccccc ccccccccccccccccc. B2 bbb bbbbbbbbbbb bbbbbbbbbbbb. B1 bbbb bbbbbbb. B3 bbbb bbbbbbb bbbb. A3 aaaaa aaaaaaaaaa A2 aaa aaaaaaaaaa aaaaaaaaaaaaa A1 aaaaa aaaaaaaaaa C3 ccccc cccccccccccccc. C3 A ccccc cccccccccccccc. C3 A-1 ccccc cccccccccccccc. C1 ccccc ccc ccccccccccccccccc. C2 cccccccc ccccccccccccccccc. A1 aaaaa aaaaaaaaaa B1 bbbb bbbbbbb. C1 ccccc ccc ccccccccccccccccc. C3 ccccc cccccccccccccc. C3 A ccccc cccccccccccccc. C3 A-1 ccccc cccccccccccccc. A1 aaaaa aaaaaaaaaa A2 aaa aaaaaaaaaa aaaaaaaaaaaaa A3 aaaaa aaaaaaaaaa B1 bbbb bbbbbbb. C1 ccccc ccc ccccccccccccccccc. A2 aaa aaaaaaaaaa aaaaaaaaaaaaa A3 aaaaa aaaaaaaaaa B1 bbbb bbbbbbb. C1 ccccc ccc ccccccccccccccccc. A2 aaa aaaaaaaaaa aaaaaaaaaaaaa A3 aaaaa aaaaaaaaaa B2 bbb bbbbbbbbbbb bbbbbbbbbbbb. C3 ccccc cccccccccccccc. B2 bbb bbbbbbbbbbb bbbbbbbbbbbb. C3 ccccc cccccccccccccc. B2 bbb bbbbbbbbbbb bbbbbbbbbbbb. C3 ccccc cccccccccccccc. A1 aaaaa aaaaaaaaaa B1 bbbb bbbbbbb. C1 ccccc ccc ccccccccccccccccc. C3 ccccc cccccccccccccc. A1 aaaaa aaaaaaaaaa B1 bbbb bbbbbbb. C1 ccccc ccc ccccccccccccccccc. C3 ccccc cccccccccccccc. C3 A ccccc cccccccccccccc. C3 A-1 ccccc cccccccccccccc. C3 ccccc cccccccccccccc. C3 A ccccc cccccccccccccc. C3 ccccc cccccccccccccc. C3 A ccccc cccccccccccccc. C3 A-1 ccccc cccccccccccccc. C3 ccccc cccccccccccccc. C3 A ccccc cccccccccccccc.Importing
+ catalogs/abc-mixed-up_catalog.xmlIn catalog
+ catalogs/abc-mixed-up_catalog.xml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Profile
+ req-include-all-asis.xml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Result
+ output-expected/req-include-all-asis_RESOLVED.xml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Importing
+ catalogs/abc-simple_catalog.xmlIn catalog
+ catalogs/abc-simple_catalog.xml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Profile
+ req-include-by-id.xml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Result
+ output-expected/req-include-by-id_RESOLVED.xml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
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.
+