Adjust direction prop constraint and other related constraints for interconnection and other network components #2077
Conversation
The information appears to repeat information about a related prop name regarding IPv6 connectivity.
This adds the prop constraint as requested in usnistgov#1913 feedback. Also align enum doc strings to be consistent in the props for future refactoring entity file refactoring in the following commit.
As there will duplicate values when they really need to be identical and the enum documentation strings were previously aligned, it is prudent to refactor the reused enum values and doc strings using the shared entity file pattern per other shared allowed-values enum sets in this model definition and others.
| </allowed-values> | ||
| <allowed-values target="[@type=('service', 'software')]/prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal')]/@name"> |
There was a problem hiding this comment.
Per discussion in #1913 and refining the issue as posed by the comment in #1913 (comment), I am not sure why leveraged system typed components would not have similar need for like software and service, but I wanted to leave that open to interpretation here during the PR review.
| <allowed-values target="[@type=('service', 'software')]/prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal')]/@name"> | |
| <allowed-values target="[@type=('service', 'software', 'system')]/prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal')]/@name"> |
| @@ -213,6 +215,7 @@ | |||
| <matches target="prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal') and @name='isa-date']/@value" datatype="date-time"/> | |||
| <matches target="prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal') and @name='ipv4-address']/@value" datatype="ip-v4-address" /> | |||
| <matches target="prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal') and @name='ipv6-address']/@value" datatype="ip-v6-address" /> | |||
| <matches target="prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal') and @name='uri']/@value" datatype="uri" /> | |||
There was a problem hiding this comment.
This was not explicitly requested in #1913 (comment), but it standards to reason we make sure it is a URI, not just a string value for a prop with the .[@name="uri"]. Open question: the documentation string defines this as a URI, we are sure we do not mean a URL to access the interconnect with a given scheme/authority, host, path, or is it really just an identifier. I think some (Brian and Michaela know this detail), but URIs and URLs are related in terms of type signature. In Metaschema, they would use the same type.
Committer Notes
Closes #1913.
All Submissions:
By submitting a pull request, you are agreeing to provide this contribution under the CC0 1.0 Universal public domain dedication.
(For reviewers: The wiki has guidance on code review and overall issue review for completeness.)
Changes to Core Features:
Have you written new tests for your core changes, as applicable?Have you included examples of how to use your new feature(s)?Have you updated all OSCAL website and readme documentation affected by the changes you made? Changes to the OSCAL website can be made in the docs/content directory of your branch.