What this all boils down to is that we should make these elements all
inherit @resp from a class -- then at least they'd have to be consistent!
Cf discussion about @target and @targets at last council meeting (see sf
feature request #2531384 )
James Cummings wrote:
> Gabriel Bodard wrote:
>> James Cummings a écrit :
>>> Not with note/@resp but with something like origDate/@resp, you can
>>> have multiple pointers. Unlike with persName/@ref the Guideline
>>> reference pages to seem to say what multiple pointers mean, but I
>>> would have interpreted <date resp="#E1 #E2"> as that E1 and E2 are
>>> both in some manner responsible for the determination of the element
>> Me too. If you want to say that the resp is _either_ E1 or E2, then I
>> think we're in the territory of using <certainty/>, aren't we?
> That would certainly be one way to do it.
>> For the above use-case, however, I'd be in favour of standardizing @resp
>> to allow multiple pointers more widely (maybe even universally).
> I certainly don't disagree. While I do agree with the others that the
> current method is really to point to a personGrp or similar, I can't
> think of good semantic reasons why: add, del, affiliation, birth, death,
> event, gap, nationality, origPlace, persName, person, sex, state, trait,
> etc. (random selection from att.editLike) allow a @resp with multiple
> pointers and many other elements allow only a single one.
> Those that don't are:
> att.interpLike [interp interpGrp span spanGrp]
> att.textCritical [lem rdg rdgGrp]
> <gap/> allows multiple @resp values but <space/> does? So multiple
> people can be responsible for excluding a bit of text but only one can
> be responsible for noticing that there is a bit of extra space?