-
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
ID conventions for OSCAL document #221
Comments
I will produce a stylesheet to help us scan and validate ID (values and format) against their components (document position, label, and type - which may or may not always align). This will give us some leverage for designing a robust ID assignment protocol, which will reflect all the requirements. Final resolution of this issue may require some emendation/"correction" of the source data see #218. Any rule we make must be able to produce consistent IDs for components that need them but do not now have them. |
NB also @anweiss asks important questions regarding confidence that these IDs can have universal scope not only document scope. To support this, we need at least to be able to enforce robust identifiers at the top level as well. |
Status Meeting: 8/23/2018@wendellpiez , @joshualubell and @iMichaela will meet on Tuesday to discuss this issue. |
Sprint 13 Progress Aug 30 2018 Meeting with @iMichaela and @joshualubell Tue Aug 28, we confirmed a strategy:
Following the meeting I made progress yesterday on implementation. It is 50% there. Progress towards goal (putting this issue to bed for this data set): 70% (including work of analysis/spec) |
In my repo there is now a file implementing the ID protocol. It also has links from Objectives to corresponding items in the control statement. FWIW these IDs are extracted by mapping from given labels, so GIGO, meaning if the link integrity holds up that is all credit to the file originators. (Comparing these identifiers with systematically generated IDs is another thing.) Unfortunately the file is largish that is beginning to be a concern even to me (even if it compresses fairly well). next up: find and correct remaining glitches w/ more comprehensive validation of values expected and (re)presented; survey to see where IDs are still missing. |
The file at the link above has just been committed again. I am continuing to review and to develop tooling to support review. Note in particular in objectives there are now |
Oops there is still at least one glitch see e.g. id value |
At least that has now been corrected to |
More review has been performed and more issues found. Please don't merge just yet. :-) |
Okay to consider the latest commit (again) of the file cited above. The data set is passing more and more stringent Schematron tests. (Next will be to write up the specification of the rules being enforced.) |
** Sprint 13 Progress Report Sep 5 2018 ** Much progress including not only IDs and labels but a few other improvements found along the way. Additionally, a Schematron is now given which confirms the structured numbering. I am hoping this is 90% done now. It requires review. Work on the readme is also proceeding. |
9/6/2018 Status MeetingThis is addressed in PR #229. |
Sprint 13 Progress September 27 2018 It becomes clear that there are really two issues here:
Since #229 has been merged, the first of these can and should proceed, assuming no outstanding PRs touch the SP800-53 catalog and profiles. (The user community should also be helpful here.) The second of these depends on Issue #196. |
A file documenting ID conventions observed in the SP800-53 catalog is now behind PR #237. Please take a look @anweiss @iMichaela thanks! |
A file describing the catalog including notes on conventions followed in ID assignment is now located here: |
Sorry i didn't see this thread, before I posed my ticket. #248. |
User Story:
As an OSCAL content creator and/or user, I can refer to a set of clear and concise conventions for the use of the
id
attribute in an OSCAL document.Goals:
The only constraint on the
id
attribute in an OSCAL document today is that it conforms to thexsd:ID
type; meaning that it must start with a letter or underscore, and can only contain letters, digits, underscores, hyphens, and periods (http://www.datypic.com/sc/xsd/t-xsd_ID.html). In addition to this, we should also publish best practices and conventions for the use of theid
attribute. Questions one might ask:<catalog id="usnistgov_[catalog_name]">
Dependencies:
This is somewhat related to #39, although that issue pertains to the use of the
id
attribute in controls rather than the use of theid
attribute in a complete OSCAL document. The issue also depends on #218.Acceptance Criteria
The use of the
id
attribute in an OSCAL document has well-defined conventions associated with it.The text was updated successfully, but these errors were encountered: