Add validation for cases that use the "EASList" value in the @...Encoding attributes of <control>

[kerstarno]

Creator of issue

1. Kerstin Arnold
2. EAD team lead, TS-EAS
3. @kerstarno
4. [email protected]

The issue relates to

• EAC-CPF schema issue
• EAC-CPF Tag Library issue
• EAD schema issue
• EAD Tag Library issue
• Schema issue
• Tag Library issue
• Suggestions for all schemas
• Suggestions for all Tag Libraries
• Other

Wanted change/feature

• Text: This feature request follows Remove fixed value lists eas-schemas#1. With the decision to define the use of value lists via @...Encoding attributes within <control>, users can decide to use the "EASList" for values in the respective attributes within the descriptive part of EAD or any other, i.e. their own lists (either completely different from the EAS lists or an extension of them.
• For now, the "EASList" value essentially picks up on the values that have been predefined for these attributes in EAD3 (respectively EAC-CPF 2.0) and this is what Schematron should check against. In the context of finalising EAD 4.0, these values should be checked and it should be reviewed whether any other values should be added.
• For now, this check only applies to the draft of EAD 4.0. EAC-CPF 2.0 would first need to be revised with regard to removing the predefined value lists.

• If addressLineTypeEncoding is used with the value "EASList", the @addressLineType attribute should only contain one of the following values: county, country, district, municipality, postBox, postalCode, region, street
• If @audienceEncoding is used with the value "EASList", the @audience attribute should only contain one of the following values: external, internal
• If contactLineTypeEncoding is used with the value "EASList", the @contactLineType attribute should only contain one of the following values: directions, email, fax, homepage, mobileNumber, phoneNumber
• If coverageEncoding is used with the value "EASList", the @coverage attribute should only contain one of the following values: part, whole
• If detailLevelEncoding is used with the value "EASList", the @detailLevel attribute should only contain one of the following values: basic, extended, minimal
• If descriptionOfComponentsTypeEncoding is used with the value "EASList", the @descriptionOfComponentsType attribute should only contain one of the following values: analyticOverview, combined, inDepth
• If levelEncoding is used with the value "EASList", the @level attribute should only contain one of the following values: class, collection, file, fonds, item, recordGroup, series, subfonds, subgroup, subseries
• If maintenanceEventTypeEncoding is used with the value "EASList", the @maintenanceEventType attribute should only contain one of the following values: cancelled, created, deleted, derived, revised, unknown, updated
• If maintenanceStatusEncoding is used with the value "EASList", the @maintenanceStatus attribute should only contain one of the following values: cancelled, deleted, deletedMerged, deletedReplaced, deletedSplit, derived, new, revised
• If physDescStructuredTypeEncoding is used with the value "EASList", the @physDescStructuredType attribute should only contain one of the following values: carrier, materialType, spaceOccupied
• If publicationStatusEncoding is used with the value "EASList", the @publicationStatus attribute should only contain one of the following values: approved, inProcess, published
• If statusEncoding is used with the value "EASList", the @status attribute should only contain one of the following values: alternative, authorized, ongoing, unknown
• If unitDateTypeEncoding is used with the value "EASList", the @unitDateType attribute should only contain one of the following values: bulk, inclusive

Note: While most of the values listed above have been kept as they are in EAD3 (respectively EAC-CPF 2.0), some have been adapted to camelCasing respectively to full length. These values are:

• "analyticOverview" and "inDepth" for @descriptionOfComponentsType
• "recordGroup" and "subgroup" for @level
• "materialType" and "spaceOccupied" for @physDescStructuredType
  The spelling of these attribute values will hence need to be adapted as part of the general conversion to EAD 4.0, which will be developed in one of the next stages of the revision process.

[fordmadox]

These lists should be ready for testing now. Thanks for compiling this ticket so thoroughly!!!

[kerstarno]

Tested with XSD and RNG (both including the Schematron) and can confirm that this is implemented as expected for the attributes @audience, @coverage, @detailLevel, @descriptionOfComponentsType, @level, @maintenanceEventType, @status, @unitDateType as well as the respective @…Encoding attributes.

However, when I add @contactLineTypeEncoding with the value "EASList", the attribute @contactLineType does not seem to be checked as it can remain empty and can have other values than the ones defined in the "EAS list" (e.g. "abc"). The same applies to the attributes:

• @maintenanceStatus when having added @maintenanceStatusEncoding with the value "EASList"
• @physDescStructuredType when having added @physDescStructuredTypeEncoding with the value "EASList"
• @publicationStatus when having added @publicationStatusEncoding with the value "EASList"

I've also realised that I forgot the attribute @addressLineTypeEncoding in the initial list. This has now been added (see top of the list in description above).

It should also be noted that - for now - the Schematron does not require these @...Encoding attributes when the respective attributes are used in the <control> or <archDesc> sections. I.e. these attributes can currently still be used without their encoding having been defined.

[fordmadox]

Should be ready again for testing, minus the last point, which is not currently enforced. I would also expect that we wouldn't preclude someone from using a value from an EASList (e.g., 'country') when not using the "EASList" setting?

[kerstarno]

Re-tested with the XSD and the RNG (including the "ead4" branch Schematron) and can confirm that this now also works for @addressLineType, @contactLineType, @maintenanceStatus, and @physDescStructuredType plus their respective @...Encoding attributes.

For @publicationStatus (with @publicationStatusEncoding) it works with the RNG, but not with the XSD.

My last note in the previous comment was only for documenting this. Eventually, I would expect that the Schematron gives a message that, when using one of the relevant attributes in the <control>, <findAidDesc> or <archDesc> sections, one should set the related @...Encoding attribute in the <control> element. And, yes, if the @...Encoding attribute is set to "other...Encoding" values from the EAS lists would also be valid as the "other...Encoding" option covers completely different lists as well as lists that expand upon the EAS lists.

[kerstarno]

Adding @marieelia as eventually this might also apply to EAC-CPF given that it would be expected for EAC-CPF to also remove the predefined values from attributes and to use the @...Encoding attributes in <control> instead.

Also, for reference: the point about ensuring that <control> does include the relevant @...Encoding attribute(s) depending on which attributes are used in the <control> and in the descriptive sections is addressed in #4.