Open kerstarno opened 7 months ago
These lists should be ready for testing now. Thanks for compiling this ticket so thoroughly!!!
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.
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?
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.
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.
Creator of issue
The issue relates to
Wanted change/feature
Text: This feature request follows https://github.com/SAA-SDT/eas-schemas/issues/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.
[x] 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[x] If
@audienceEncoding
is used with the value "EASList", the@audience
attribute should only contain one of the following values: external, internal[x] 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[x] If
coverageEncoding
is used with the value "EASList", the@coverage
attribute should only contain one of the following values: part, whole[x] If
detailLevelEncoding
is used with the value "EASList", the@detailLevel
attribute should only contain one of the following values: basic, extended, minimal[x] If
descriptionOfComponentsTypeEncoding
is used with the value "EASList", the@descriptionOfComponentsType
attribute should only contain one of the following values: analyticOverview, combined, inDepth[x] 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[x] 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[x] 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[x] 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[x] If
statusEncoding
is used with the value "EASList", the@status
attribute should only contain one of the following values: alternative, authorized, ongoing, unknown[x] If
unitDateTypeEncoding
is used with the value "EASList", the@unitDateType
attribute should only contain one of the following values: bulk, inclusiveNote: 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:
@descriptionOfComponentsType
@level
@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.