Replies: 4 comments 13 replies
-
So, as we discussed on the meeting, there is already a way to organize OVAL documents in this way: use of external references. Can we somehow try and use this feature (improved maybe) to make is less backward-incompatible? I'd really hate to kick out extended definitions. |
Beta Was this translation helpful? Give feedback.
-
Two observations:
|
Beta Was this translation helpful? Give feedback.
-
Encapsulated definitions look much easier to maintain, but I understand the benefit of allowing references to previously described objects and states. So, how about a hybrid approach, where you can refer to objects and states previously defined in other definitions? Something like this:
to allow the reuse of object previously defined with that id. This is similar to what happens in the YAML language, for instance. And a tool would be able to quickly crossreference the id and provide a preview or a link to it. |
Beta Was this translation helpful? Give feedback.
-
in compliance as code, we already write oval files not in an encapsulated form, but in a "single view" e.g.: The only thing is that the build of a product (generating the output oval, datastream, xccdf) will make sure to put the each tag under its correct place. Because if this is to make development easier, the way we do at compliance as code is simple enough. |
Beta Was this translation helpful? Give feedback.
-
@OVAL-Community/oval-board-members
During our meeting on 09-26-2024, the board was not able to come to a consensus regarding redesigning OVAL definitions.
Pros:
Cons:
Existing 5.12 format with several silos of information
Proposed 6.0 format with encapsulated definitions
Discussion will end on 10-04-2024 with voting to occur on 10-07-2024
Beta Was this translation helpful? Give feedback.
All reactions