Profile resolution metadata resolution chooses a difficult to obtain value for metadata/last-modified

[GaryGapinski]

Describe the bug

The fourth bullet "Metadata Resolution" in "OSCAL Profile Resolution Specification Draft" asserts "The value of metadata:last-modified in the target MUST be set with a valid timestamp representing the time the profile resolution completed." [emphasis mine]. This requires extraordinary effort to achieve when using pure XSLT for profile resolution. Use of XPath current-dateTime() during a transformation will typically provide the time of transformation initiation.

Who is the bug affecting

Implementors of OSCAL profile resolution.

What is affected by this bug

Documentation

How do we replicate this issue

A pure XSLT profile resolution implementation will likely use the XPath current-dateTime() function to obtain the date+time+timezone at the time of profile resolution. This is often (but not always) the point in time at which the XSLT transformation commenced. The actual time of resolution completion cannot be obtained without extraordinary effort.

Expected behavior (i.e. solution)

If profile resolution is considered an atomic operation the actual time of completion could instead be the time of resolution initiation, a time during resolution, or the time of resolution completion, or an arbitrary time elected by the rainha da resolução. Some latitude in the precise choice of asserted completion time would be gratefully received.

If for some reason the time of completion is important, a strict definition of completion is lacking and elusive.

Other comments

No response

[galtm]

@GaryGapinski , I like your point about latitude in the precise choice. I think it makes sense in light of the part of the current-dateTime function's spec that says, "This function is deterministic. The precise instant during the query or transformation represented by the value of fn:current-dateTime() is implementation-dependent." I am not aware of a situation where the time of completion would be important by itself. If an end user were concerned about an imported catalog changing during the resolution process and not knowing whether the resolved profile reflects the latest catalog changes, such a user would need more timestamps than merely when the profile resolution process completed.

On the other hand, if the OSCAL community decides that the profile resolution spec draft shouldn't change this bullet after all, the XSLT profile resolver could get a fresher timestamp by executing a second transform (identity plus setting the timestamp) after the existing profile resolution pipeline ends. The second transform could be mentioned in the manual instructions and added to the wrapper script.

[aj-stein-nist]

The team is in favor loosening the wording of the specification, will consider this a potential issue for an upcoming sprint.

[wendellpiez]

I concur the language should be loosened. Like @GaryGapinski , I am used to a world in which everything-happens-all-at-once.

Yet I am also not sure how a test could determine that a timestamp had been "prematurely" applied (reflecting initiation rather than conclusion of a black-box process). I.e. to validate conformance to a strict reading of this line of the spec. So it may be an unenforceable rule.

[nikitawootten-nist]

Fixed via #1900

[aj-stein-nist]

We need to prioritize work to include processing specifications (now profile resolution only) for generating them like before, as the content site and reference site are no longer managed within the same repo. We need to get generated specs automatically deploying like reference material, even in OSCAL-Reference perhaps. :-)

We need to move on usnistgov/OSCAL-Reference#16 in short order. Thanks for pointing this out during sprint review @nikitawootten-nist.