You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
I believe that
<choice>
and the elements ofmodel.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:
(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.The text was updated successfully, but these errors were encountered: