Elements order in Schema

[SJagodzinski]

Question wether to force an order of elements in the schema or not.

Creator of issue

1. Silke Jagodzinski
2. TS-EAS: EAC-CPF subgroup
3. [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

During EAC-CPF revision the question came up if we want to force an elements order in the schema or not.

If the elements sequence is defined by the schema file, it has to be adopted by the Tag Library, but only in the element. description.

Reporting a bug

Suggested Solution

Options:

1. required, but not repeatable elements
2. required, repeatable elements (possibly in any order)
3. optional, but not repeatable elements (possibly in any order)
4. optional, repeatable elements (possibly in any order).

Steps to Reproduce (for bugs)

Context

Chicago meeting outcome:

To make EAC-CPF use easier the enforced order is only for <control> and <cpfDescription>

See also @fordmadox comments in #138 and #214

[fordmadox]

Despite the decision made during the Chicago meeting, it turns out that there is a technical issue with allowing ANY order within certain elements like description when the allowed elements have mixed cardinality requirements (e.g. 0..1 and 0..N) when deriving to XSD 1.0. Although XSD 1.1 easily supports this requirement, in the same way that the RNG schema does, we do not have an RNG --> XSD 1.1 conversion option available (as far as I'm aware), but even if we did, some tools, like JAXB, do not yet support XSD 1.1 (and so, we'd still need to have an XSD 1.0 solution). But, the 1.0 solution would need to be maintained as a separate step in our publication pipeline, and writing it is quite difficult for the amount of interleaving elements (but here's how it can be formulated in XSD 1.0, https://stackoverflow.com/a/12012599, for reference).

Long story short: since we have a few elements that mix cardinality like this, we'd either need to introduce new wrapper elements, eliminate the mixed cardinality another way (e.g. allow elements to repeat or not be bound in one-off wrapper elements), or just go with an enforced order. I'd suggest going with the above ordering of required/optional elements and adding something to our design principles about this. Thoughts?

[kerstarno]

As indicated in #214, I have created a document in our Shared Drive under "Subteam working documents > SchemaTeam > 2020-2021" where I have listed so far all elements from the current XSD draft for EAC-CPF 2.0 that contain sub-elements in a specific sequence. I will aim to have the document completed with additional elements from the current XSD for EAD3 (deprecated) latest for the January meeting of the Schema team, if not already for the January meeting of the EAC team.

With regard to EAC-CPF, I think the suggested solution above works in most cases, though we might want to consider having a rule that says that <objectXMLWrap> and <descriptiveNote> will always come last independent of their cardinality. If such rule were followed, there only are two additional cases, where the suggested solution leads to seemingly "unorganised" sequences that we might want to review and confirm:

• <control> where <recordId> and <otherRecordId> would be separated by at least <maintenanceAgency> and <maintenanceHistory> as well as potentially <sources> if the latter is used;
• <identity> where <entityType> and <otherEntityTypes> (if used) would be separated by <nameEntry> and/or <nameEntrySet> and where <identityId> (if used) would be moved towards the end (before <descriptiveNote>).

[kerstarno]

Following the Schema Team meeting on 12 January, this document here lists all the EAC-CPF elements, where the order of sub-elements will need to change:

https://github.com/SAA-SDT/TS-EAS-subteam-notes/blob/master/schemas-subteam/working-documents/20210112_ElementsOrder_Final_EAC-CPF.pdf