Remove fixed value lists

[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: Discussing further alignment between the EAS in the context of the EAD revision meetings in Boston and The Hague end of August and beginning of September 2022 has covered <control> among other elements to reconfirm that the changes introduced with the release of EAC-CPF 2.0 will also work in the context of EAD. It has been suggested to remove the predefined lists of value for the new attributes @maintenanceStatus, @publicationStatus, @agentType, and @maintenanceEventType and to change their data type to NMTOKEN to allow for any text. The current value lists could still be mentioned in the tag libraries as recommendations, but shouldn't be seen as the only options.

[kerstarno]

@fordmadox @karinbredenberg @marieelia

At the EAC team meeting on 1 September, it was decided that this question should be expedited to the whole committee as it will also affect EAF in future.

(P.S.: I don't seem to be able to add assignees, hence I'm mentioning you all directly.)

[kerstarno]

Update (4 January 2024):
Following the EAD team's meeting on 15 December and in relation to the changes suggested with #58 and #65 among others, the details of this issue have been updated (see latest comment with date of 4 January 2024). The current development version of the schema still represents what is outlined in this comment, though further changes are necessary, which might require another round of testing.

The topic was discussed in a series of EAD team and Schema team meetings in preparation to the the all-committee meeting in February, when four options were presented and compared including example encodings for illustration. Following this meeting, all TS-EAS members were asked to vote for their preferred option.

The overall preference went to the option that suggested to extend the concept of the @...Encoding attributes that already exist in <control>, e.g. @dateEncoding, and define in one place for the whole EAS XML file which standard or vocabulary is followed to provide - in this case - normalised date information. Adapted to the attributes that currently use predefined value lists in the EAD and EAC-CPF schemas, the intent is to create @...Encoding attributes within <control> for each of these with the values "EASList" or "other[nameOfTheAttribute]Encoding". This would go hand-in-hand with highly recommending that a definition or reference to a definition of any value lists other than the EAS list is provided within <conventionDeclaration>. This would apply to cases when the EAS list is mainly extended by a few local values in the same way as when a completely different list of values is used.

Here is a list of changes resulting from this decision.

Note for working on and testing this issue: When the schema changes are done in development branch, please mark the tasks on the highest levels of the list (printed in bold) by ticking the box. When the changes have been tested successfully, please mark the tasks on the lowest level of the list and - if existing - on the mid-level of the list (printed in italics) by ticking the box. If there is only one level in the list, finalised schema changes in the development branch should be marked by adding a comment to this issue, while successful testing will be marked by ticking the box.

• Add the following attributes with these values to <control>
  • For EAD and EAC-CPF
    • @detailLevelEncoding; “EASList”, “otherDetailLevelEncoding”
    • @maintenanceStatusEncoding; “EASList”, “otherMaintenanceStatusEncoding”
    • @publicationStatusEncoding; “EASList”, “otherPublicationStatusEncoding”
    • @maintenanceEventTypeEncoding; “EASList”, “otherMaintenanceEventTypeEncoding”
    • @agentTypeEncoding; “EASList”, “otherAgentTypeEncoding”
    • @audienceEncoding; “EASList”, “otherAudienceEncoding”
    • @addressLineEncoding; “EASList”, “otherAddressLineEncoding”
    • @contactLineEncoding; “EASList”, “otherContactLineEncoding”
    • @statusEncoding; “EASList”, “otherStatusEncoding”
    • @targetTypeEncoding; “EASList”, “otherTargetTypeEncoding”
  • Only for EAD
    • @coverageEncoding; “EASList”, “otherCoverageEncoding”
    • @daoTypeEncoding; “EASList”, “otherDaoTypeEncoding”
    • @dscTypeEncoding; “EASList”, “otherDscTypeEncoding”
    • @levelEncoding; “EASList”, “otherLevelEncoding”
    • @physDescStructuredTypeEncoding; “EASList”, “otherPhysDescStructuredEncoding”
    • @unitDateTypeEncoding; “EASList”, “otherUnitDateTypeEncoding”
  • Only for EAC-CPF
    • @identityTypeEncoding; “EASList”, “otherIdentityTypeEncoding”
• Ensure the data type for the following attributes is token (updated after decision on Review and align the use of data type token and NMTOKEN #50 on 11 January)
  • For EAD and EAC-CPF
    • @addressLineType
    • @agentType
    • @audience
    • @contactLineType
    • @detailLevel
    • @maintenanceEventType
    • @maintanceStatus
    • @publicationStatus
    • @status
    • @targetType
  • Only for EAD
    • @coverage
    • @daoType
    • @dscType
    • @level
    • @physDescStructuredType
    • @unitDateType
  • Only for EAC-CPF
    • @identityType
• Remove @other... attributes (only EAD)
  • @otherLevel from <archDesc> and from numbered and unnumbered <c>
  • @otherDaoType from <dao>
  • @otherDscType from <dsc>
  • @otherPhysDescStructuredType from <physDescStructured>
• Remove @localType attribute from the following elements
  • For EAD and EAC-CPF
    • <addressLine>
    • <contactLine>
  • Only for EAD
    • <dao>
    • <relationEntry> (note: <relationEntry> will be converted to <targetEntity>, which has @targetTypebut no @localType, so this bullet point is mainly for reference)

[fordmadox]

Updating now, but a thought: why don't we simplify the otherX options and just provide the following two options for each: EAS OR other. We haven't gone the wacky route of suggesting that we include values like "EASListLevelEncoding" so why would need an "otherLevelEncoding" value when "other" will suffice (and be simpler)?

[karinbredenberg]

Comments from first testing:

• @addressLineTypeEncoding is named @addressTypeLineEncoding in the schemas, i.e. "Type" should be after "Line"
• @contactLineTypeEncoding is named @contactTypeLineEncoding in the schemas, i.e. "Type" should be after "Line"
• @status is not updated yet
• @dscType not implemented yet
• @level not implemented yet
• @physDescStructuredType not implemented yet

[kerstarno]

Re-tested with XSD and RNG for the changes related to EAD 4.0.

All aspects listed above have been solved with the exception of the attribute @descriptionOfComponentsType still missing from <descriptionOfComponents>. I have created a pull request for the respective change (#77). Once this pull request has been merged, this issue needs a final round of testing.

[fordmadox]

Thanks for the pull request! Should be test-able again now.

(That said, if we were to really aim for simplification, I think that reversing the EAD3 decision of having separate 'elementNameType' attributes, and instead having one 'type' attribute, would be the way to go, and is implied already by how attribute nodes are related to the element node).

[kerstarno]

Re-tested again with the XSD and the RNG and can confirm that @descriptionOfComponentsType is now available with data type "token" but without any predefined values with <descriptionOfComponents>.

[kerstarno]

As for the question about the @...Type attributes in general, it could indeed be an argument to say that, if we include an option to encode types and roles - which also was highly recommended as part of the relations conversation - that we do so in elements rather than attributes (e.g. for reasons of multilinguality and for enabling the use of the vocabulary attributes where possible and appropriate.

On the other hand, only having a generic @type attribute (1) might make it rather tedious if one wanted to defined a value list for this attribute but would have to take into account a large variety of rather different use cases and contexts (this is assuming that we'd still have a @typeEncoding option within <control>) and (2) would - as a follow-up - bring back the question of the necessity for @localType (which would already be covered if one used "otherTypeEncoding" instead of a potential "EASList".

There also might then be the question of why we'd have the @type attribute only with certain elements, but not with others. In the current draft for EAD 4.0, that last point is addressed by the circumstance that those elements with specifically named ...Type attributes also have an "EASList" option for the values of these attributes, while all other elements have @localType for anyone to use as they see fit.