Open ronaldtse opened 5 years ago
https://www.metanorma.com/author/topics/document-format/requirements-recommendations-permissions/ : documentation of what we have
https://github.com/metanorma/metanorma-requirements-models: formal model, UML and RNC grammar
URL update for OSCAL sample: https://raw.githubusercontent.com/usnistgov/OSCAL/master/content/nist.gov/SP800-53/rev4/xml/NIST_SP-800-53_rev4_catalog.xml
I guess the second URL is now: https://pages.nist.gov/OSCAL/documentation/examples/
OSCAL structure: Top level containers: "profile", "catalog" Sub-containers: "metadata", "group", "back-matter", "import", "merge", "modify" Sub-sub-containers: "control", "prop", "link", "role", "party", "responsible-party", "org", "address", "addr-line", "param", "part", "citation", "resource", "rlink", "insert", "call", "include" Attributes and elements: "title", "last-modified", "version", "oscal-version", "org-name", "city", "state", "postal-code", "email", "party-id", "label", "target", "as-is", "desc" Sub-sub-container attributes: "name", "rel", "href", "class", "media-type", "id", "param-id", "control-id", "role-id", "position"
title -> the same as in Metanorma
last-modified (date and time)
version (date)
oscal-version
role -> defines different roles using attribute "id" which can take values 'creator' and 'contact'
party -> defines parties
responsible-party -> defines a responsible party; similar as subject in Metanorma
Wow. Thank you @anermina. I don't have the headspace to investigate this now, but this gives me a start. And I can already see that this is radically different to the modelling we have done...
Under the new thinking, OSCAL represents one way of modeling a requirement. Metanorma should support multiple ways of modeling requirements, and for sure we should support OSCAL.
No longer a priority
Sample: https://raw.githubusercontent.com/usnistgov/OSCAL/master/content/nist.gov/SP800-53/rev4/NIST_SP-800-53_rev4_catalog.xml