Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

choice element and members of model.choicePart should all claim membership of att.typed #2697

Open
jamescummings opened this issue Apr 4, 2025 · 0 comments

Comments

@jamescummings
Copy link
Member

I believe that <choice> and the elements of model.choicePart should all have the type attribute (or membership of att.typed).
The test for this kind of request is usually whether they are repeatable and whether you can think of a reason you might classify one some way or the other. I believe this is true for all these elements. Certainly, inside choice all of these are repeatable and thus people may wish to distinguish between them and I can see ways that I want to.

Currently in model.choicePart:

  • Those with att.typed already:
    • abbr, am, corr, reg, seg
  • Those without att.typed:
    • choice, ex, expan, orig, sic, supplied, unclear

(though the truth is I only care about choice, ex, expan, orig, and sic, but I'd stand by the principle).

My logic is that having it on abbr but not expan, for example, is completely indefensible because it presupposes a direction of choice, the original might have the expansion and one might be choosing to note its abbreviated form. (North Atlantic Treaty Organization -> NATO). You might well have multiple forms of expansion as well, all of which are alternatives of each other.

With all these, but for example orig one might have multiple versions of the original form -- not different readings from textual witnesses (that you'd use rdg for) but different interpretations of the same string of original text. One might also have multiple sic with different understanding of the original error. It also seems straightforward to want to do simple classification of the choice element itself (e.g. what form of choice this is regardless of its child elements).

I think rationalising this across these model.choicePart and choice is a straightforward regularisation of their attributes.

One could also argue that these should all have att.editLike (some do, some don't). The reason is that it was presumed that the 'original' views such as orig, sic, and (falsely) abbr, didn't need things like @evidence because they were the original, not the interpretative normalisation. However, the establishing of the orig, sic, or abbr may well be done owing to internal or external evidence just as much as the reg, corr, or expan versions. All markup is interpretation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant