search

SAA-SDT / EAD3

https://www.loc.gov/ead/index.html
Creative Commons Zero v1.0 Universal
80 stars 25 forks source link

Allow <foreign> in <ref> #522

Closed kerstarno closed 4 years ago

kerstarno commented 5 years ago

Creator of issue

  1. Kerstin Arnold
  2. Archives Portal Europe Foundation
  3. Email: kerstin.arnold.berlin@gmail.com
  4. GitHub: @kerstarno

The issue relates to

Wanted change/feature

Reporting a bug

Suggested Solution

Steps to Reproduce (for bugs)

1. 2. 3. 4.

Context

Your Environment can be a clue to a bug

noahgh221 commented 5 years ago

Hi @kerstarno , I'm not aware of any reason why <foreign> was specifically excluded from the list of valid child elements of <ref>. I can add this request as a discussion item for the next EAD Team meeting.

Out of curiosity, did you have a specific use case for this, or did you just notice this possible oversight while reviewing the schema?

rockivist commented 5 years ago

I can't recall with certainty, but I think this was an oversight. When we revised the linking elements, I know we were careful to exclude ref from the children of ref, which is why ref doesn't include m.mixed.basic (which would make ref recurse). We set up the element definition of ref with its own group of element references.

My guess is that we did that before foreign was introduced to the schema (it was a late addition). So when we added foreign to m.mixed.basic, we must have forgotten to add it separately as a child to the m.mixed.basic elements that don't have that content model.

I think adding foreign as a child of ref would be a good idea. Looking at the other m.mixed.basic elements, I don't see anywhere else it was missed.

kerstarno commented 5 years ago

Hi @noahgh221 - thanks for taking this up. And, to answer your question: no specific use case in mind, only came across this while going through EAD3 in the context of the Shared Schema work.

@rockivist - thanks for the "trip back in time" and the confirmation :-)

fordmadox commented 5 years ago

I'm beginning to look forward to the prospects of a shared schema :)

In the meantime, I've added a patch for this in the "issue_522" branch. If the EAD3 group decides to include this update in a future minor release, then I will regenerate the six different EAD3 schema variants for testing and release purposes.

@noahgh221 we should discuss whether we'll continue to need all of those variants, but in this particular case I don't anticipate any issues in doing that (aside from the extra time it takes to create and test those). but if we do move to a shared schema with the EAC revision, then we could simplify how the schemas are created, quite significantly, if we not only harmonize the "driver" schemas but also the schema deliverables.

noahgh221 commented 5 years ago

Thanks @fordmadox , I don't see any reason why we would not want to include this patch, but let's discuss logistics in Austin. I'm also seeking some clarity/decision on how we should manage and schedule these minor revisions, which we should also discuss in Austin.

kerstarno commented 4 years ago

In their meeting on 23 September 2019, TS-EAS EAD team decided that this bug should be corrected. Issue is therefore assigned to the leads of the Schema team for next steps.

fordmadox commented 4 years ago

This is already noted, but just a reminder that we'll also need to update the tag library with the release of version 1.1.1 See https://www.loc.gov/ead/EAD3taglib/index.html#elem-ref

fordmadox commented 4 years ago

Closing this out since the change has been merged.