descgrp bug in ead3_undeprecated.dtd

[rockivist]

The undeprecated version of the EAD3 DTD has a bug in the element definition for the descgrp element. It should allow both the block elements (chronlist|list|table|blockquote|p) and the full set of did siblings (accessrestrict|accruals|acqinfo|altformavail|appraisal|arrangement|bibliography|bioghist|controlaccess|custodhist|descgrp|fileplan|index|legalstatus|odd|originalsloc|otherfindaid|phystech|prefercite|processinfo|relatedmaterial|relations|scopecontent|separatedmaterial|userestrict).

However, in testing the updated style sheets for support of undeprecated migration, I noticed the migrated descgrps weren't validating correctly in the DTD. The RNG and XSD seem to be fine.

[rockivist]

@fordmadox I've been testing the 1.1 release candidate and this bug persists in the
new ead3_undeprecated.dtd. Still not sure why the transformation from the RNG to the DTD isn't working for this specific element (and it is working in the undeprecated RNG and XSD), but I've fiddled with the undeprecated DTD and I think I know what needs to change there.

In the RC undeprecated DTD, the relevant code for descgrp is as follows:

<!ELEMENT descgrp (head?,((chronlist|list|table|blockquote|p),(accessrestrict|accruals|acqinfo |altformavail|appraisal|arrangement |bibliography|bioghist|controlaccess |custodhist|descgrp|fileplan|index |legalstatus|odd|originalsloc |otherfindaid|phystech|prefercite |processinfo|relatedmaterial|relations |scopecontent|separatedmaterial |userestrict))+)>

If I change it to the following everything validates in my test files:

<!ELEMENT descgrp (head?,(chronlist|list|table|blockquote|p|accessrestrict|accruals|acqinfo |altformavail|appraisal|arrangement |bibliography|bioghist|controlaccess |custodhist|descgrp|fileplan|index |legalstatus|odd|originalsloc |otherfindaid|phystech|prefercite |processinfo|relatedmaterial|relations |scopecontent|separatedmaterial |userestrict)+)>

I suppose you and @tcatapano could investigate why the descgrp element isn't translating properly from the RNG to the DTD, but I don't think it's a good use of anyone's time. Could you make a manual change in the 1.1. branch? I'm happy to make the change myself if you prefer.

[fordmadox]

@rockivist I just made that change and updated the branch. I haven't had a chance to look at the branch yet, but I'll try to investigate later to see what happened with the transformation.

[fordmadox]

I'll hold off on creating a new release until after we've figured this issue out, along with the objectxmlwrap issue.

[fordmadox]

@rockivist regarding this issue, i'm probably daft (or just not understanding the history of this issue), but when would this have been merged with master? i don't see it anywhere in the history of commits: https://github.com/SAA-SDT/EAD3/commits/master sorry if this is just one of those end-of-the-day questions on my part :)

[rockivist]

@fordmadox I just made a fix in ead3_undeprecated-driver.rng in the branch issue_503. Will issue a PR.

[fordmadox]

Just a note that this popped up again after running the transformations. I'm going to manually edit the undeprecated DTD after the transformation this time, and send out a new release later today.

[fordmadox]

Manually fixed, and ready to test again: https://github.com/SAA-SDT/EAD3/releases/tag/v1.1.2-beta

[rockivist]

@fordmadox Looks good in the 1.1.2 release. I say it's good to go.

[kerstarno]

Issue review in preparation to upcoming EAD subteam call on 23 September:

@fordmadox - can this issue be closed?

[fordmadox]

@kerstarno we'll need to keep this open for now. Mike tried a fix for this, but unfortunately the bug persists once the DTDs are regenerated from the RNG schema. I have not had a chance to investigate. We should keep this issue open until either: a) the bug is fixed, and we don't need to manually edit the derived 'undeprecated' DTD; or b) we agree to stop providing the undeprecated versions of EAD3. As I recall, there was no commitment to continue providing all six versions of EAD3 after the initial release.

[kerstarno]

Following the previous comment, EAD team decided during their meeting on 3 December 2019 to assign this issue to @fordmadox as the Schema team lead as a reminder in the context of future schema releases.