[tei-council] [Fwd: [ tei-Feature Requests-2531384 ] Rationalise application of @target]

[Lou Burnard]

Here's a ticket I just created, calling attention to some inconsistency 
in the way we define @target


The attribute @target is explicitly defined for 12 elements. Four
others inherit it from a class (populated only by the dictionary
module). However, the details of its definition in each of these
sixteen cases are not at all consistent.

Optionality:

In 11 cases (including the 4 from the class), it is a required attribute.
In 5 cases, it is either optional or "rwa" which means effectively optional

Cardinality:

In 8 cases it can take 1:many values.  In 8 cases (including the 4
from the class) it can take only one value.  (There are also three
cases of @targets, but these are all consistently defined as taking
2:more values)

Alternative methods:

In 4 cases, the @target attribute is provided in alternation with a
@cRef attribute (i.e. a RelaxNG schema will allow you to have either
one or the other, but not both) The @cRef pointing mechanism allows a
subset of the methods available from @target, using a different
TEI-defined syntax.

What should we do about this?

a. Nothing
b. Define a class for the most common case (required, singleton
value)
c. Either allow @cRef consistently or deprecate, and then abolish, it
d. Ditto for @targetEnd


Here's the complete breakdown

element	   	    optionality	cardinality	other
=====================================================
att.ptrlike.form-oRef	req	1
att.ptrlike.form-oVar	req	1
att.ptrlike.form-pRef	req	1
att.ptrlike.form-pVar	req	1
catRef			req	m	@scheme
certainty		req	m
fsdLink			req	1
gloss			opt	1	@cRef
locus			opt	m	@scheme
note			rwa	m	@targetEnd
ptr			req	m	@cRef
ref			opt	m	@cref
respons			req	m
specGrpRef		req	1
term			opt	1	@cRef
witDetail		req	m




----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=644065&aid=2531384&group_id=106328