You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #1386, the profile resolution requirement labeled "req-meta-oscalversion-error" refers to Semantic Versioning 2.0 as part of the error checking logic. This logic suggests two questions:
Will OSCAL versions always conform to the Semantic Versioning 2.0 spec?
If so, should the OSCAL schema enforce the pattern that Semantic Versioning 2.0 uses? Currently, oscal-version is a string, which is far less restrictive.
The Semantic Versioning 2.0.0 spec includes regular expressions that can facilitate implementation; see the bottom of this page: https://semver.org/spec/v2.0.0.html
If the answer to question 1 is yes, how tolerant should profile resolvers or other tools be when processing oscal-version strings? For instance, if a profile indicates the OSCAL version as " 001.2 " rather than "1.2.0" should the tool error out or silently correct the nonconformant aspects (leading/trailing space, leading zeros in 001, and missing "z" part of the x.y.z string)? In #1420 so far, I've made the code silently correct some nonconformant aspects that are feasible to correct. I can change the behavior based on the outcome of this discussion.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
In #1386, the profile resolution requirement labeled "req-meta-oscalversion-error" refers to Semantic Versioning 2.0 as part of the error checking logic. This logic suggests two questions:
The Semantic Versioning 2.0.0 spec includes regular expressions that can facilitate implementation; see the bottom of this page:
https://semver.org/spec/v2.0.0.html
If the answer to question 1 is yes, how tolerant should profile resolvers or other tools be when processing oscal-version strings? For instance, if a profile indicates the OSCAL version as " 001.2 " rather than "1.2.0" should the tool error out or silently correct the nonconformant aspects (leading/trailing space, leading zeros in 001, and missing "z" part of the x.y.z string)? In #1420 so far, I've made the code silently correct some nonconformant aspects that are feasible to correct. I can change the behavior based on the outcome of this discussion.
Beta Was this translation helpful? Give feedback.
All reactions