-
Notifications
You must be signed in to change notification settings - Fork 179
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
App development would be easier if group id's were required rather than optional in Catalog and Profile #1299
Comments
As a consumer, you'll probably need to handle older data, which may not have the group id. So I'm not sure its really going to save effort. If it had been required from 1.0, then I can see the advantage, but it seems limited value now. |
@fsuits should these IDs be required and unique or simply required? |
@hahsanti The group ids are currently optional, but must be unique when provided. One driver to allow groups without ids is to allow the catalog author to decide which groups are intended to be addressed by an id and which groups to not allow addressing in this way. @fsuits This would be a backwards compatibility breaking change, so we could only consider this for an OSCAL 2.0.0 release. |
One could imagine the evolution of a REST API to include things like adding a new control to a group, i.e.:
and that existing group could not be referenced without a group ID. |
What would it mean for the API to support the following, given precious little details and just what-if-ing on the fly?
{
"groups":
[
{"id": "group1.a", "control-ids": ["g1a-1", "g1a-2"] },
{"id": null, "control-ids": ["gnoid-3", "gnoid-4"] }
]
}
It seems that your proposed endpoints around |
At a high level I think we want the REST API
When we look at the scenario of adding a new control to an existing group, we need to reference that group by a unique identifier. With an optional group ID there could be two groups with
Correct, not in the specification yet. We wanted to validate the approach with the community before going 'too deep' on the spec. To be clear, I was just using REST APIs and this scenario as an example of where we might need to reference a group, which is a clear indicator that it needs an ID. |
Makes sense. I (personally, not speaking for the team) can agree with that.
Understandable and totally agree with the approach.
Yes, also completely reasonable and understandable. I think you did reframe the wording around this scenario.
You described this better than I did. I know this is kludgey, but until 2.0 time frame, what would stop the API specification and developers from allowing |
The issue there is that we can't rely on order of JSON array elements in many implementations. It's entirely possible that the response of I think the best short-term solution would be for the REST API to essentially layer additional constraints on the OSCAL models and state that group IDs are required/will be generated. We're doing something similar already by declaring that UUIDs must be scoped to the entire implementing system rather than just the OSCAL document.
I haven't looked in detail, but yes, I would assume there are other instances of this problem. |
Just to be clear, I called it a kludge not because I thought it was an elegant and fully complete design. :-) I meant it as more of a workaround if the OSCAL model will not change short term around a required group ID. Is the intent that your catalogs could be dynamically generated? If we look at them is static or semi-permanent database of control items, I had not really thought about your point about your point re serialization and deserialization in different runtimes and their implementations re arrays, so point well made! |
With regard to the question of other optional id's, I believe the only optional id's are for groups, either in catalogs or profiles, and for parts. Parts are very granular and usually in a well defined context - so I can understand it would be somewhat overkill to require an id for them, while at the same time it might be convenient to allow one. In contrast, groups are relatively coarse-grained and each control has a well defined path in a catalog that allows direct access. It will either be in the catalog's list itself, with no group at all, or follow a path of catalog->group->group->group->control->control->control - in the most general case. Without group id's this path becomes hard to specify - unless you assign group id's on the fly. I created this issue from the perspective of a developer, since it is cleaner to rely on certain attributes to be present and not deal with situations of available/not_available and corresponding fallback logic. I'm not clear on the use case of wanting to prevent direct access to a group - and since groups have titles (that may not be unique) you can still use the title somewhat as a group id - at least for narrowing the search of where a control lives. My preference as a developer is to have group id's be unique and required - while titles are completely flexible. This would help any part of code, or a REST interface, where the direct path to access the group or a control is needed without a search. A specific need in trestle is the ability to map a catalog's group structure to a filesystem directory, where subgroups are simply named subdirectories based on the group id. Without a required id, temporary ones would be needed. |
We discussed this on the 6/24 model review and agreed that group identifiers need to remain optional to avoid a backwards compatibility breaking change. This can be revisited in OSCAL 2.0.0. |
At the 11/30 Triage Meeting: The team decided to pursue this ticket in the next version of OSCAL. |
User Story:
As an OSCAL application developer, coding logic would be simpler and clearer if group id's in Catalog and Profile groups were required rather than optional.
Goals:
Groups are present in Catalogs and in Profiles, and in each case the schema specifies a required title and an optional group_id. Since groups may be nested, and since the id is intended to allow direct reference to the specific group in a document, it makes sense for the id to be required rather than optional. This adds a small burden to the document creator - but would simplify application developers since they would not need to do special handling when the group id is not present - e.g. create an internal id on the fly during processing.
Dependencies:
No dependencies other than a change in the schema. There are presumably few use cases where the group id's are not already specified in a catalog or profile.
Acceptance Criteria
The text was updated successfully, but these errors were encountered: