We currently don't have any special tests for unitDate in the same way we do for the single date elements (date, fromDate, toDate)

[fordmadox]

Ideally, these two elements will merge (since structured dates can benefit from textual description, and textual description dates already do not require machine-readable date attributes in EAD), but until then, we should likely not allow such encodings like the following:

<unitDate notAfter="2024whatayear"/>

Simple to address in the Schematron, but it begs the question about why we have the two elements still, since why provide an encoding choice to users to encode an equivalent (but in this case Schematron-valid) statement such as:

<unitDateStructured><date notAfter="2024"/></unitDateStructured>

Allowing both goes against our first schema-design principle, anyway.

[fordmadox]

Decision: yes, update, as long as "otherDateEncoding" option is not specified.

[kerstarno]

Actually, the issue is not about <unitDate> compared to <unitDateStructured>, but compared to <date>, <fromDate>, and <toDate>, which can be used in various other elements next to <unitDateStructured>.

While testing https://github.com/SAA-SDT/eas-schemas/issues/88, I also found that there seems to be some inherent check somewhere in the Schematron which expects ISO 8601 compliant dates (respectively some value at all to start with) for @standardDate, @notAfter, and @notBefore in <date>, <fromDate>, and <toDate> even if @dateEncoding is not specified at all.

Example:

• <control> does not include @dateEncoding. Adding @standardDate, @notAfter, and/or @notBefore to <date>, <fromDate>, and/or <toDate> will result in validation errors, if these attributes remain empty (or include a value not compliant to the ISO standard). If @standardDate, @notAfter, and/or @notBefore are added to <unitDate>, however, no validation errors are detected while they remain empty (or include a value not compliant to the ISO standard).
• <control> does include @dateEncoding with the value "iso8601". Adding @standardDate, @notAfter, and/or @notBefore to <date>, <fromDate>, and/or <toDate> with values not compliant to the ISO standard will result in validation errors. If @standardDate, @notAfter, and/or @notBefore are added with values not compliant to the ISO standard to <unitDate>, however, no validation errors are detected.
• <control> does include @dateEncoding with the value "otherDateEncoding". Only in this case, @standardDate, @notAfter, and/or @notBefore can also remain empty - or have any value - when used in <date>, <fromDate>, and/or <toDate>, same as when used in <unitDate>.

[kerstarno]

This is what should ideally happen when validating with the Schematron:

• A check that @dateEncoding is available in <control>, whenever the attributes @standardDate, @notAfter, and/or @notBefore are used - independent from the element with which these attributes are used.
• If @dateEncoding is set to the value "iso8601", the values of all iterations of the attributes @standardDate, @notAfter, and/or @notBefore need to be compliant with the ISO standard - independent from the element with which these attributes are used.
• If @dateEncoding is set to the value "otherDateEncoding", the values of all iterations of the attributes @standardDate, @notAfter, and/or @notBefore can be anything (or rather nothing that would be checked by the standard Schematron provided by TS-EAS) - independent from the element with which these attributes are used.

[fordmadox]

Right, the current approach was modeled off of EAD3's schematron approach (if I recall correctly), such that the only time the dates were not expected to be ISO-8601 was if and only if the dateEncoding was set to "otherDateEncoding". So, setting dateEncoding = to iso8601 was equivalent as leaving it off, just like setting audience = external was equivalent to leaving that attribute blank.

I'll update the new EAD4 Schematron to use the 3 rules as explained above, though. Once that's added to the issue_7 branch, I'll note the commit here.

[fordmadox]

Should be ready to test now, in both this branch and the 'ead4' branch.

[kerstarno]

Tested the following scenarios:

• No @dateEncoding in <control>
  • XSD (with Schematron)
  • Adding an empty @standardDate, @notAfter, or @notBefore to <date>, <fromDate>, or <toDate> results in the error message: "The notBefore, notAfter, and standardDate attributes of date must match the TS-EAS subprofile of valid ISO 8601 dates." I.e. the XSD already seems to be expecting ISO 8601, even though @dateEncoding is not set. -> At this point the message should be the same as in the RNG, i.e. asking for @dateEncoding to be set.
  • Adding an empty @standardDate, @notAfter, or @notBefore to <unitDate>, however, still doesn't give any message. -> This should be the same as for the other three elements.
  • RNG (with Schematron)
  • Adding an empty @standardDate or @notAfter to <date>, <fromDate>, or <toDate> results in the error message: "If the @standardDate, @fromDate, or @toDate attributes are utilized in the file, you must set @dateEncoding on the control element." -> This is the correct reaction, but the message should say "@notBefore, or @notAfter attributes" instead of "@fromDate, or @toDate attributes".
  • The same is true when adding an empty @standardDate or @notAfter to <unitDate>. -> This is the correct reaction, but the message should say "@notBefore, or @notAfter attributes" instead of "@fromDate, or @toDate attributes".
  • However, adding an empty @notBefore to any of these four elements without having set the @datenEncoding in <control> does not give any error message. -> This should be the same as for an empty @standardDate and @notAfter.
• @dateEncoding with value "iso8601" in <control>
  • XSD (with Schematron)
  • Adding an empty @standardDate, @notAfter, or @notBefore to <date>, <fromDate>, or <toDate> or using a non-ISO 8601 compliant value (e.g. "abc") results in the same error message as above: "The notBefore, notAfter, and standardDate attributes of date must match the TS-EAS subprofile of valid ISO 8601 dates." -> This is correct.
  • Adding an empty @standardDate, @notAfter, or @notBefore to <unitDate> or using a non-ISO 8601 compliant value, however, still doesn't give any message. -> This should be the same as for the other three elements.
  • RNG (with Schematron)
  • Adding an empty @standardDate, @notAfter, or @notBefore to <date>, <fromDate>, <toDate>, or <unitDate> or using a non-ISO 8601 compliant value (e.g. "abc") now results in the error message: "The notBefore, notAfter, and standardDate attributes of date must match the TS-EAS subprofile of valid ISO 8601 dates." -> This is correct.
• @dateEncoding with value "otherDateEncoding" in <control>
  • XSD (with Schematron)
  • @standardDate, @notAfter, or @notBefore in <date>, <fromDate>, <toDate>, or <unitDate> can be left empty or can have any value without any error message. -> This is correct.
  • RNG (with Schematron)
  • @standardDate, @notAfter, or @notBefore in <date>, <fromDate>, <toDate>, or <unitDate> can be left empty or can have any value without any error message. -> This is correct.

[fordmadox]

@kerstarno : can you check the 'ead4' branch again? I think that I got most of the issues, but I wasn't able to replicate (or understand) some of the behavior that you noticed, specifically with unitDate.

[kerstarno]

Re-tested with the XSD and the RNG (including the "ead4" branch Schematron) and can confirm that this now works as expected.

When no @dateEncoding is set (yet) in <control> and I add @notBefore, @notAfter, or @standardDate to <unitDate>, <date>, <fromDate>, or <toDate>, I get the message that @dateEncoding needs to be set.

When I've got @dateEncoding set to "otherDateEncoding" and I add @notBefore, @notAfter, or @standardDate to <unitDate>, <date>, <fromDate>, or <toDate>, these can remain empty and they can have any value.

When I've got @dateEncoding set to "iso8601" and I add @notBefore, @notAfter, or @standardDate to <unitDate>, <date>, <fromDate>, or <toDate>, these cannot remain empty and their values have to conform to the ISO standard.

As a note: @standardDate allows date ranges according to ISO 8601 (i.e. something like "1900/1910"), while @notBefore and @notAfter only allows single dates according to ISO 8601. I assume that does make sense with regard to how these two attributes are meant to give one earliest respectively latest date, but if someone wanted to e.g. say "not before the 18th century" in a standardised way according to ISO 8601, the value "1701/1800" would not be valid in @notBefore with the current setting. (Only noting this down for reference, not saying we should or shouldn't allow it.)

[kerstarno]

I've created a schemas issue to follow up on the question raised re date ranges in @notBefore and @notAfter. With this plus the successful testing plus seeing that the aspect of appropriate alert messages in the schematron is already being addressed in the context of #10, I am closing this issue here.