#167 Rationalise application of @target

AMBER
closed
nobody
None
5
2010-05-02
2009-01-23
Lou Burnard
No

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

Discussion

  • Lou Burnard

    Lou Burnard - 2009-03-14
    • milestone: --> 871207
     
  • Dot Porter

    Dot Porter - 2009-04-02

    (message to the listserv)
    Dear Everyone,

    Lou's request outlines well the various ways that @target is defined, which seems to be a reflection of time more than anything else. As for what is to be done, he has four suggestions, and my comments follow

    a. Nothing

    Tempting for simplicity but not the best option

    b. Define a class for the most common case (required, singleton
    value)

    I like the idea of having a class, and this seems to be the simplest and most popular option.

    c. Either allow @cRef consistently or deprecate, and then abolish, it

    I don't like either of these ideas. @cRef on e.g. <note> or <locus> simply doesn't make sense (I suppose one might create a note pointing to a canonical reference but I can't really see it), but as someone who has used @cRef on <ref> for pointing to biblical references it's a nice one to have.

    d. Ditto for @targetEnd

    This issue was taken care of under FR 2494567, in which @targetEnd has been depreciated for new encoding in favour of target="range()" (although @targetEnd has not been and will not be, I think, removed)

     
  • Lou Burnard

    Lou Burnard - 2009-04-02
    • milestone: 871207 --> 871208
     
  • Lou Burnard

    Lou Burnard - 2009-04-02

    make @target point to 1:n, and define as class; enforce in schematrron

     
  • Lou Burnard

    Lou Burnard - 2009-10-13
    • milestone: 871208 --> AMBER
     
  • BODARD Gabriel

    BODARD Gabriel - 2009-12-09

    Lou's recommendation (below) makes sense to me, I think. A couple of questions (I was going to raise this in council teleconf, but we ran out of time):

    * does it always make sense to allow more than one value in @target?

    * If not, then in cases where it doesn't can we define exceptions for specific elements?

    * If not, do we care? After all, local usage has to define if more than one value is actionable anyway...

    * re Dot's point about @cRef below: does it actually do any harm to define this attribute more consistently (in parallel to @target, for example), even if in a couple of cases we can't quite see how it would be used? (There are plenty of attributes in att.editLike that make no sense on some elements in that group...)

     
  • Lou Burnard

    Lou Burnard - 2010-04-30

    Decision to introduce class for 1:n values reaffirmed; @targets to be deprecated; add those 3 to same class; we did not discuss cRef, so this issue should be resubmitted.

     
  • Lou Burnard

    Lou Burnard - 2010-04-30
    • status: open --> closed
     
  • Sebastian Rahtz

    Sebastian Rahtz - 2010-04-30
    • status: closed --> open
     
  • Lou Burnard

    Lou Burnard - 2010-05-02

    Implemented as much as poss at rev 7436. More specifically:

    1. Removed @type from existing att.pointing so that it now supplies @target. Added existing att.pointing members to att.typed where they did not locally define @type (e.g. with specific vallists). Add ptr, ref, term, gloss, locus, note, witDetail, catRef, link, join, alt to att.pointing; also add all current members of att.ptrLike.form, which is now therefore redundant.

    2. Added schematron rules to link, join and alt. Remove references to @targets in prose of SA; tidy up prose a tiny bit.

    3. No change made in use of @cRef yet. Also note that respons and certainty still get their @target from att.scoping, along with the much discussed @match.

     
  • Lou Burnard

    Lou Burnard - 2010-05-02
    • status: open --> closed