Is there a need for "anti-pattern" or "not-recommended" but valid OSCAL content examples?

[iMichaela]

A community member created PR #270 proposing the creation and maintenance of OSCAL content that validates per OSCAL schemas and constraints but which demonstrate not-recommended practices.

Community's perspective is solicited. NIST perspective is the our team with support form the community should focus on best practices examples as having a stronger educational impact, since they provide guidance toward a path forward. Any adopter that does not know how to move forward might not gain any insight from not-recommended use cases.

[davaya]

Much has been written about "enabling constraints", the idea that limiting possibilities may simplify understanding and increase productivity. The purpose of negative examples is not to educate content developers, but to illustrate where future OSCAL releases might add simplifying constraints while encouraging the community to point out valid use cases that would be precluded if the constraint were adopted.

[iMichaela]

I agree that many but not all of the existing constraints should not be part of the core OSCAL. But I fail to understand the direct relation between this problem space (relaxing some constraints) and the anti-pattern or negative examples issue. My top priorities are the prototype models that need updates and examples before being released, the errors we identified, conflicting constraints or incorrectly defined like the port range error) and examples (good examples for now)
With that said, finding the best approach for identifying the constraints we should relax is important.

[davaya]

Because Task and Activity are already defined, consider a hypothetical new assembly "Function" proposed for inclusion in Assessment-plan. We start with two user requirements: functions must be globally reusable, and functions must composable from other functions. I am proposing adding a constraint: functions must be defined directly within the Assessment-plan/functions field, not nested within other functions. My rationale for the constraint is that it is both simpler for content authors to understand and more efficient for content to be reused.

Positive examples show that the user requirements are satisfied with the proposed constraint accepted. Negative examples show what could happen without the constraint, e.g., functions used more than once result in their definitions being copied in multiple locations, which raises the possibility of copy-paste inconsistencies (the same UUID used with different content).

So the problem isn't always "relaxing constraints" (although it could be for existing models that don't follow them), it is deciding whether to define a constraint that embodies best practices without making it more difficult for content creators to satisfy their requirements.

Another proposed constraint, not yet discussed, is that unqualified names shall be unique within OSCAL scope. This is violated by Control-implementation, Group, Statement, Select-control-by-id, and Implemented-requirement. An anti-pattern example would use two definitions with the same name, requiring them to be qualified by model.