OSCAL 1.0.5 No longer accepts Georgian Format?

[Telos-sa]

Question

Validated the new 1.0.5 schema to see if we need to do any refactoring of the code.

Here is what it looks like in the SSP output:
2023-04-24T00:00:00.000Z

command run to validate with schema
xmllint -schema /Users/13503/Desktop/oscal_ssp_schema.xsd /Users/13503/Desktop/Xacta-SaaS_OSCAL-export_20230424/Xacta-SaaS_OSCAL-export_20230424.xml --noout

and the generated error.
/Users/13503/Desktop/Xacta-SaaS_OSCAL-export_20230424/Xacta-SaaS_OSCAL-export_20230424.xml:7: element last-modified: Schemas validity error : Element '{http://csrc.nist.gov/ns/oscal/1.0}last-modified': [facet 'pattern'] The value '2023-04-24T00:00:00.000Z' is not accepted by the pattern '(((2000|2400|2800|(19|20-9))-02-29)|(((19|2[0-9])[0-9]{2})-02-(0[1-9]|1[0-9]|2[0-8]))|(((19|2[0-9])[0-9]{2})-(0[13578]|10|12)-(0[1-9]|[12][0-9]|3[01]))|(((19|2[0-9])[0-9]{2})-(0[469]|11)-(0[1-9]|[12][0-9]|30)))T(2[0-3]|[01][0-9]):([0-5][0-9]):([0-5][0-9])(.[0-9]*[1-9])?(Z|(-((0[0-9]|1[0-2]):00|0[39]:30)|+((0[0-9]|1[0-4]):00|(0[34569]|10):30|(0[58]|12):45)))'.
/Users/13503/Desktop/Xacta-SaaS_OSCAL-export_20230424/Xacta-SaaS_OSCAL-export_20230424.xml:7: element last-modified: Schemas validity error : Element '{http://csrc.nist.gov/ns/oscal/1.0}last-modified': '2023-04-24T00:00:00.000Z' is not a valid value of the atomic type '{http://csrc.nist.gov/ns/oscal/1.0}oscal-metadata-last-modified-FIELD'.

Can it be confirmed if this structure is no longer accepted, and give an example of the expected structure, and/or determine if this is a bug?

[GaryGapinski]

I can confirm this anomaly using this schema — note the v1.0.5 branch in the URL: 2023-04-25T11:06:14Z is considered valid, while 2023-04-25T11:06:14.000Z is considered invalid, which is incorrect. However, the v1.0.5 schema does not match the regex expression cited in this issue. The regex portion (.[0-9]*[1-9])? cited in this issue does not escape the full stop introducing an optional fractional second and additionally does not accommodate an all-zeroes fractional second. The regex portion in the v1.0.5 schema is (\.[0-9]*[1-9])? which does escape the full stop but does not accommodate an all-zeroes fractional second.

However, I'm seeing anomalous variants in different branches and tags.

The XPath expression (evaluated using Saxon-PE 11.4) '2023-04-25T11:06:14.000Z' castable as xs:dateTime returns true. XML Schema date and time data types are discussed in XML Schema Part 2: Datatypes Second Edition appendix D. Fractional seconds are optional and when present may have an arbitrary level of precision, including trailing zeroes (e.g., .123000).

Contrast with — note the main branch in the URL — current version (asserts it is v1.0.4) which is also incorrect (escapes the full stop but demands a non-zero fractional second portion).

Contrast with this variant which asserts it is v1.0.4 and has a correct fractional second regex portion.

[aj-stein-nist]

The team has reviewed this and was able to reproduce the bug like Gary was able to. More analysis is needed to know where the disconnect is with the fix from #1206 and its integration into a pre-release the resolution of #1703.

[aj-stein-nist]

We are waiting for an upstream PR to receive feedback and merge finalized changes for usnistgov/metaschema#379 to move up the submodule, resolve this issue, and create a follow-on release.

[aj-stein-nist]

Marking blocked until Metaschema PR reviewed and merged.

[aj-stein-nist]

Closing with 1.0.6. pre-release.

[Telos-sa]

YAY!!! Is there an OSCAL CLI dev branch that I can test from?

[aj-stein-nist]

YAY!!! Is there an OSCAL CLI dev branch that I can test from?

@Telos-sa, stay tuned, you are looking for the current commit of the release-1.0 branch specifically at the v1.0.6 tag. Announcement forthcoming.

https://github.com/usnistgov/OSCAL/releases/tag/v1.0.6