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 have this very vague recollection¹ that when @edRef was invented the intent was that it would be used as an alternate to @ed. As evidence (besides the fact that it just makes sense), of the 19 examples that include either @ed or @edRef, none include both @ed and @edRef. However, @edRef is basically not mentioned in the prose of the Guidelines at all,² so it is hard to know. Further, I quite suspect that as soon as I suggest that they should be in strict alternation with one another (i.e., only one or the other should be legal on any given instance of an element that is a member of att.edition, either because we put org="choice" on the <attList> that contains them or add some Schematron to enforce this alternation) @martindholmes will come up with a use case that demonstrates it is useful to have both.
But in the case where we leave it legal to have both of them on the same element instance, we need to say what it means. I submit the answer to that question is either
a) they indicate separate editions, or
b) they are different ways of indicating the same edition (in the same order).
Although I suppose we could say “these Guidelines do not assert the intended semantics when both are specified” or some such. (Ick!) Personally, I would prefer the “only one or the other is allowed on any given element” approach.
notes
¹ Vague because, I think, I was not on Council at the time and did not pay it much heed.
² Only mentioned once in DR to say “<lb> additionally bears the attributes @ed and @edRef, from its membership …”, not what to do with them at all.
The text was updated successfully, but these errors were encountered:
You're right @sydb, I will. A sigil is not the same as a pointer, and I imagine one might well want to specify a sigil in the context of a specific edition while simultaneously pointing to an external bibliographical resource. But this is not my area of expertise, I'm so we need input from people who use these attributes regularly.
I am pretty sure that when @edRef was invented it was precisely thought of as an alternative to @ed -- there are after all plenty of other attributes one might use for pointing to external bibliographic resources in general.
I have this very vague recollection¹ that when
@edRef
was invented the intent was that it would be used as an alternate to@ed
. As evidence (besides the fact that it just makes sense), of the 19 examples that include either@ed
or@edRef
, none include both@ed
and@edRef
. However,@edRef
is basically not mentioned in the prose of the Guidelines at all,² so it is hard to know. Further, I quite suspect that as soon as I suggest that they should be in strict alternation with one another (i.e., only one or the other should be legal on any given instance of an element that is a member of att.edition, either because we putorg="choice"
on the<attList>
that contains them or add some Schematron to enforce this alternation) @martindholmes will come up with a use case that demonstrates it is useful to have both.But in the case where we leave it legal to have both of them on the same element instance, we need to say what it means. I submit the answer to that question is either
Although I suppose we could say “these Guidelines do not assert the intended semantics when both are specified” or some such. (Ick!) Personally, I would prefer the “only one or the other is allowed on any given element” approach.
notes
¹ Vague because, I think, I was not on Council at the time and did not pay it much heed.
² Only mentioned once in DR to say “
<lb>
additionally bears the attributes@ed
and@edRef
, from its membership …”, not what to do with them at all.The text was updated successfully, but these errors were encountered: