Closed wendellpiez closed 2 years ago
@david-waltermire-nist I would like to squash the commits in this PR is that easy to do? (A bunch of files were added then removed again.)
As @ohsh6o reports, this doesn't work under SaxonHE, which doesn't support calling to Java functions to provide random UUIDs.
There are several potential workarounds for this, but any of them will require further development. If we document this limitation the code could still be useful. Advice and thoughts?
It definitely would be useful to document this limitation, but I am not sure which of the alternatives is worthwhile given the objective of UUID generation and all the use cases. I presume we can document a recommended alternative, but which one is best I am not sure. Per our conversation, some alternatives:
random()
, also with custom code to leverage this is in XSL, but EXSLT is not supported by Saxon 9.x or 10.x (regardless of HE/PE/EE), so this is most undesirableDid I capture the range of common approaches correctly?
As noted, one solution is to write an extension for SaxonHE as described here: https://www.saxonica.com/html/documentation/extensibility/integratedfunctions/
A repo with examples of such extensions is here: https://github.com/docbook/xslTNG/blob/main/src/main/java/org/docbook/xsltng/extensions
If we have to roll our own in XSLT, the fn:random-number-generator()
function now supersedes older solutions for randomness.
See Issue #10
The working branch now has an XSLT ready for testing. It refreshes all UUID values in an OSCAL file, along with the data points where they are used as link targets.
For those who wish to try it, the utility is here: https://github.com/wendellpiez/oscal-tools/blob/issue10-uuid-util/xslt/uuid/refresh-uuids.xsl (The commit also includes other WIP and small updates.)
I have used the utility successfully, but not yet documented it except in comments for a maintainer.
Still to be done: