Closed kerstarno closed 9 months ago
Why would archdesc
get these two attributes but c
wouldn't?
I also had the localType pair added to the new functions
element, since I think that was mentioned in another ticket... though it's not noted above. Anyhow, I've done a first pass. Let me know what else needs to change.
Ahh... the reason I added the localType pair to functions was to align with EAC. I did the same for the rest of the new plural elements, like agents (though not listed above). Let me know if any of those attributes should be removed. If so, then we'll also need EAC-related tickets eventually.
Why would
archdesc
get these two attributes butc
wouldn't?
Because <archdesc>
already has @localtype
in EAD3, while the numbered and unnumbered <c>
elements don't. If there is a request and suitable use case to add @localType
also to the latter that could be discussed, but we haven't had it so far.
Thanks for taking care of <functions>
- that slipped through the net.
Tested with the XSD and the RNG and can confirm that this has been implemented as expected with the only exception of <agent>
, which is currently missing @localType
and @localTypeDeclarationReference
. However, I will report this in #58, so this issue here can be marked as "Tested successfully".
Creator of issue
The issue relates to
Wanted change/feature
@localTypeDeclarationReference
as an optional attribute to all elements with@localType
.@localTypeDeclarationReference
is of data type IDREFS.Update (5 January 2024): Following the EAD team's meeting on 15 December, the details of this issue have been updated to the latest status. The current development version of the schema might still represent what was outlined initially, while further changes might be necessary and require another round of testing.
Note for working on and testing this issue: When the schema changes are done in development branch, please this by ticking the box on the higher level (printed in bold); once the changes have been tested successfully please mark this by ticking the box on the lower level.
@localTypeDeclarationReference
to:<control>
see #32<archDesc>
<abstract>
<container>
(will become<dao>
<formAvailable>
, which includes@localType
and@localTypeDeclarationReference
, see #65)(same as for<daoSet>
<dao>
)renamed:<didNote>
<identificationDataNote>
<materialSpec>
<physDesc>
<physLoc>
(will become<origination>
<agent>
, which includes@localType
and@localTypeDeclarationReference
, see #58)(same as for<repository>
<origination>
)<unitTitle>
<unitId>
<accessConditions>
<accruals>
renamed:<acquinfo>
<sourceOfAcquisition>
(will become<altFormAvail>
<formAvailable>
, which includes@localType
and@localTypeDeclarationReference
, see #65)<appraisal>
<arrangement>
<bibliography>
(renamed to<publicationNote>
, see #66)<biogHist>
<controlAccess>
(renamed to<subjectHeadings>
, see #67)<custodHist>
<filePlan>
(incorporated with<index>
<subjectHeadings>
, see #67)<legalStatus>
renamed:<odd>
<otherDescriptiveInfo>
(will become<originalsLoc>
<formAvailable>
, which includes@localType
and@localTypeDeclarationReference
, see #65)<otherFindAid>
renamed:<physTech>
<physicalOrTechnicalRequirements>
<preferCite>
<processInfo>
<relatedMaterial>
<scopeContent>
<separatedMaterial>
<useConditions>
(will become<corpName>
<agent>
, which includes@localType
and@localTypeDeclarationReference
, see #58)(same as for<famName>
<corpName>
)<function>
(will be incorporated with<genreForm>
<subject>
under<subjectHeadings>
, see #67)(will become<name>
<agent>
, which includes@localType
and@localTypeDeclarationReference
, see #58)(will be incorporated with<occupation>
<subject>
under<subjectHeadings>
, see #67)(will become<persName>
<agent>
, which includes@localType
and@localTypeDeclarationReference
, see #58)<placeName>
(as replacement of<geogname>
, see #42)<subject>
<title>
(see #62)<chronList>
(see #62)<chronItem>
(see #62)<event>
<dimensions>
<physFacet>
(see #63)<footNote>
<dateRange>
<fromDate>
<toDate>
<dateSet>
<date>
(see #63)<num>
(see #63)<quote>
@localType
anymore in<addressLine>
(see #1) nor in<relations>
(see #33) nor in<relationentry>
(see #1 and #33) nor in<datesingle>
(removed, see #4)