-
Notifications
You must be signed in to change notification settings - Fork 183
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SAP constraints conflicting in the local-definition/objects-and-methods #2059
Comments
I asked the community for input on this issue and no preference on how to address it was provided from the community. Since a patch v1.1.3 is being prepared and this bug needs to be addressed, I'll remove both conflicting constraints and who needs them can enforce them as external constraints. |
OK so to confirm, you still want feedback on this issue and no change has been made in a developer repository? (That could be with or without a pull request and I could not find anything, that is why I am asking to make sure I clearly understand the ask here.) |
@iMichaela it is unclear to me what I find no documentation on its purpose, although I see where it has a cardinality of exactly 1. It does not show in any allowed-values list where it would normally have some type of description. There is a 'method' property in the catalog syntax which has an optional So I believe it is under-defined/under-documented. At a minimum, the cardinality enforcement of the property should be removed until it is better documented and exercised. |
The allowed values listed in the error ('alt-identifier, label, marking, sort-id') are the generic allowed values made available to every OSCAL prop. This portion of the content should have the same structure and constraints as
I do not see any indication that the |
THIS is incorrect:
"assessment" is not the depreciated allowed value. "method" is. |
It appears that many of the rules for control syntax are defined in the catalog metaschema instead of the controls-common metaschema. Most of these constraints also apply to profiles ( I believe the correct resolution is to move these constraints from the |
The problem with applying these to alter in profiles is that alter is cumulative, meaning a statement added by a previous alter can be altered again. This creates a case where it may be difficult to write a constraint that checks this based on the source content, as the intermediate state is not exposed to the constraint. It's easier and probably better to apply the constraints when validating the resulting catalog. |
I am summarizing here the recommended direction to fix the bug:
|
I would prefer to comment on a PR that actually shows the changes. As I mentioned before, I believe that introducing these constraints in the profile, will cause problems. If I have a PR with these changes, I can make a test case that illustrates this. When will a PR be available to comment on? |
if it helps,
i believe this constraint is conflicting with another constraint |
@wandmagic Which other constraint is it conflicting with? |
@david-waltermire I was pairing with @wandmagic and have some questions, but this solution resolves constraint violations but could use some review, even from our side of the house. |
it conflicts with
|
The caution from @david-waltermire is fair, and I hadn't considered that when I was looking at the application of constraints. While I stand by my recommendation of moving the constraint rules into the controls-common, I also agree that any application of those constraints must be surgical, and not equally applied to everyplace that might create or manipulate control content. |
Describe the bug
The constraints defined for the
assessment-plan/local-definitions/object-and-methods/part/@name
andassessment-plan/local-definitions/object-and-methods/part/prop/@name
are conflicting.The following sample:
RETURNS:
When an attempt is made to fix the errors as shown below (even if it makes no sense from the data type perspective):
the following errors are returned:
A discussion on this topic exists here:
#1968
Who is the bug affecting
All SAP developers
What is affected by this bug
OSCAL Content, Modeling
How do we replicate this issue
Run validation on the provided SAP sample .
Expected behavior (i.e. solution)
To provide correct constraints
Other comments
n/a
Revisions
No response
The text was updated successfully, but these errors were encountered: