Updated proposal for <physdescset>

[rockivist]

After further input from TS-EAD and further study and testing by me and @tcatapano, I propose the following changes. This is an updated version of the proposal I outlined in #450 (which I have now closed).

1) Rename <parallelphysdescset> as <physdescset>

The discussion of changes to <parallelphysdescset> was precipitated by comments from BYU. They specifically asked for there to be a mechanism by which to indicate that the sum of two or more part extent statements equals the whole of the materials being described. In short, they identified a need for a set of <physdescstructured> elements that are not parallel to each other. Therefore the wrapper element name should be changed to something less specific to parallel statements of extent. That said, the content model for <physdescset> should remain two or more <physdescstructured>.

2) Add @coverage as an optional attribute on <physdescset> with possible values "whole | part" (as on <physdescstructured>)

3) Add @parallel as an optional attribute on <physdescset> with possible values "yes | no"

There are two identified binaries that we are struggling to accommodate with a single element: a) does the set represent the whole or a part of the materials being described, and b) are the statements that comprise the set parallel to each other or not. Capturing these as attributes will allow for the following possible combinations:

<physdescset coverage="part" parallel="yes"> A set with coverage="part" and parallel="yes" would contain two or more extent statements parallel to each other that only describe a portion of the materials described. A set element is necessary to achieve this because its impossible to assume that two part statements describe the same portion of the component being described.

<physdescset coverage="part" parallel="no"> A set with coverage="part" and parallel="no" would bind two non-parallel extent statements that do not in sum describe the whole of the component being described. This could be used for highlighting a set of important materials as in DACS 2.5.6.

<physdescset coverage="whole" parallel="no"> A set with coverage="whole" and parallel="no" would address the use case laid out by BYU. The sum of the extent statements in the set would in aggregate describe the whole of the component being described. This would presume that the extent statements in the set were themselves all coverage="part".

<physdescset coverage="whole" parallel="yes"> A set with coverage="whole" and parallel="yes" would be comprised of two or more extent statements with coverage="whole".

In #450 I proposed that <physdescset> have an optional @localtype. I no longer think that is wise. The @coverage and @parallel attributes should provide sufficient ways to indicate the nature of the set. If a compelling case for @localtype comes up we can easily add it in a maintenance release.

In #450 I also proposed that <physdesc> be allowed as an optional child of <physdescset>. I've changed my mind about that as well. I think that for now we should keep our structured extent model separate from our legacy unstructured option. Again, if a compelling use case emerges, we can revisit this in a maintenance release without endangering forward compatibility. Better to keep <physdescset> strictly structured for now and relax it down the road if necessary than to start out too loose and attempt to tighten it up

[kerstarno-zz]

Thumbs up for this updated proposal :-)

[ruthtillman]

Thumbs up to removing <physdesc> from the equation.

DACS 2.5.6 makes me wonder if @localtype mightn't be used there to distinguish types of use. But that may be overthinking and, as you say, a maintenance update could fix that.

On the whole, it makes sense to me.

[MicheleCombs]

Works for me.

[anarchivist]

Would it be possible to change typing of @parallel in this case should be xsd:boolean, which would limit valid values explicitly using a XML Schema definition?

[tcatapano]

@anarchivist: we opted for our own defined attribute value pattern "yes|no", but it's well worth considering xsd:boolean again. I'd like to see what trang does in the conversion from RNG to DTD (though "true|false" could be added post-conversion regardless).

[rockivist]

Hearing no objections from TS-EAD and several votes of support, we will implement the proposal as described above.

@tcatapano if you have a chance to merge this into develop while you're in Europe, that would be awesome as we would have a stable target for both the migration style sheet and resuming tag library review.

[tcatapano]

@rockivist: Nothing is easy. GitHub wont do an automatic merge so I need to figure out and work out whatever conflicts there are before I can merge into the develop branch. I'd rather not rush this, but I'll try to get it done over the weekend

[tcatapano]

Merged into develop