@iMichaela Thanks. For the moment the integration is quite light:
We plan to improve the handling of user properties in the next release. @david-waltermire-nist thanks for your support
Is this workshop slide deck moved or has it been relocated somewhere?
Is there a reason we enforce
disable-output-escaping as always
true and not parameterize it? Is the processing instruction wrapper just to be cautious and inspect the JSON prior to returning it? I notice running the transform on the shell with the command line does not wrap, and I got caught trying to figure this out when converting a catalog programmaticly with eXist-DB and XQuery/XSLT, but not shell. Took me a while to figure this out.
All: I’ve mostly just lurked in this group since departing the FedRAMP PMO and the NIST OSCAL Program at the end of February, and wanted to break that silence to congratulate all of you for achieving OSCAL 1.0.0 this week!
This would not have been possible without contributions from so many of you on this channel.
We would not be here at all if Michaela hadn’t been so tenacious with her vision for OSCAL and convinced NIST to fund it, and then went on to be the champion for it across government, industry, and even across continents.
We would also not be here if not for Dave’s technical vision and leadership - keeping us prioritized and on track - and incorporating lessons learned from similar initiatives.
Wendell’s amazing knowledge of XML and its associated technologies, his ability to churn out robust XSLT, and his decades of insights/experience with similar efforts were also critical to reaching this point.
Others like Andrew, Anil, AJ, Dmitry, and Avril have all contributed significantly to OSCAL’s arrival at this point.
Departing was a difficult decision, so this week is bitter/sweet for me. I’m proud to say I was a part of this community and was able to contribute to this critical milestone.
Many vendors were waiting for 1.0.0 before they invested. Now they can!
I am eager to see all of the positive ways OSCAL will disrupt our industry.
THIS is when everything changes!
I uploaded the presentation here until #963 is merged in.
oscal-toolsrepo that could be useful (to @ohsh6o @mruge @degenero at least) - it contains an XSLT you can use to produce valid 'stub' documents. In my branch (before merging) this is at https://github.com/wendellpiez/oscal-tools/tree/updates-v1.0.0-jun2021/xslt/generate/generate-oscal.xsl
So forgive my ignorance but I am trying to track down documentation and example references that break schema. A previously existing SAP field
prop[@name=“updates-uuid’] is referenced in some remarks without a custom
@ns tag in docs, but I do not see a lot of explanation about this being supported in OSCAL.
Is this an old, obsolete, and unsupported prop in the OSCAL namespace? I cannot find anything explicitly about
updates-uuid in either NIST or FedRAMP docs.
Ok 2nd inquiry: does it stand to reason inside a
assessment-subject of a given
type that inside it you would
include-subject where it does not match the same
type? This seems repetetive but I had not noticed before.
Would you use this to exclude specific others kind of
types nested within
//assessment-subject[@type=“component”]? Because I am not sure how else you would want them to not match.