[tei-council] TARGET/s and IDREFS attributes

[Syd Bauman]

> > Yes, I think it is a worthy endeavor. The problem is, if my
> > recollection serves, that what we need are three categories:
> > 
> > * only 1 URI           currently target= of gloss, term, specGrpRef,
> >                        and tei.formPointers
> > * 1 or more URIs       currently target= of catRef, note, ptr, ref
> > * at least 2 URIs      currently targets= of alt, join, link
> > 
> > Worth toying around with what other names we might use.
> 
> There's another distinction: when the target is 2 or more URIs, 
> sometimes (as in link,join) the semantics of the element make clear 
> whether or not resolution of the link should produce a single item; 
> other times (as in note, ptr) it is not clear at all.

I'll talk about the issue itself in a minute, but first allow me to
point out that distinction you are making divides the elements almost
exactly as they are currently divided. <alt>, <join>, and <link> fall
into the category where the semantics are quite clear (for <alt> the
targets are alternatives to one another; for <link> the targets are
associated by whatever semantic is associated with the type= of the
<link>, and for <join> the targets are to be thought of as a single
element) and lo and behold, the name of their attribute is targets=.
The semantics of multiple pointers are not as clear for <note>,
<ptr>, and <ref>, and lo and behold the name of their attribute is
target=. The only outlier is <catRef>, for which the semantics of
multiple values are clearly defined (the text falls into more than
one classification category), but the value is target=.


> In P4 (and I see it has survived unchanged in your revision for
> P5) there is an example like this for a table of contents <ptr
> target="p213 p245"/> 

Could you point me to the specific example you have in mind? I
can't seem to find it.


> How does one decide whether this means "pages 213-245" or "pages
> 213 and 245"? Most of the examples in CO and elsewhere suggest
> that the latter is the more likely intention; 

My recollection is that the Guidelines never explicitly say that
generic target="#A #B" means "A & B" as opposed to "A through B,
inclusive", or vice-versa; but as you point out quite a few examples
demonstrate the "A & B" usage.


> yet there is an explicit statement in SA to the contrary! ("when
> the target attribute specifies more than one element, the
> indicated elements are intended to be combined or aggregated in
> some way...").

I do not understand how saying "A and B should be combined or
aggregated in some way" at all implies that A *through* B should be
combined or aggregated (although it does leave that possibility open,
a loophole that perhaps we should close, perhaps not).


> Well, I haven't checked all the examples where URIlists have been
> used but I'll bet most of them will fall foul of this usage rule.

I'm not sure I understand -- you think most examples of attributes
which are declared as URIlist and have multiple URIs in their value
will be ambiguous as to whether "A & B" or "A through B" is intended?
I really doubt that, but if there's any real danger someone (I can
already hear myself getting elected) should go through 'em and make
it clear which is intended. Are there any cases for which "A through
B" would be the intended semantic?


> I suggest the following:
> 1. target should *always* be a single URI
> 2. targets should *always* be a URIlist
> 3. Current cases where target takes a list of URIs should all be checked 
>    and fixed as follows:
>    - if the URIlist components are discrete (i.e. not to be aggregated), 
>      they should be represented by multiple <ptr>s
>    - if the said components *are* to be aggregated, this should be done by 
>      means of an intermediate <join>.

By "case" do you mean an attribute & element combination or an
individual example in the Guidelines?

Seems to me all <catRef> and <note>s will fall into the discrete
category. I like the idea of removing target= from <catRef> and
giving it <ptr> children:

  element catRef {
     tei.global.attributes,
     catRef.attributes.scheme,
     ptr+
  }

But <note> already has content, and a <ptr> may well already be a
child of <note>, for good reason:
  <note target="#RelaxNG01">For an introduction,
    see <ptr target="http://www.relaxng.org/compact-tutorial-20030326.html"/>.</note> 
Where do you suggest the new <ptr>-as-target= go?


The "aggregated points to <join>" idea only makes sense when the
aggregation is not some generic aggregation, but is specifically an
aggregation of XML elements for the purpose of creating a single
virtual element. In which case, I very much like this idea, as it's
already what I would recommend.


A counter proposal:
* <gloss>, <term>, <specGrpRef>, and tei.formPointers (<oRef>,
  <oVar>, <pRef>, <pVar>) get target= declared as URI (i.e., no change)
* <catRef>, <note>, <ptr>, and <ref> get targets= declared as URIlist
  (i.e., change their target= to tagets=)
* what used to be targets= of <alt>, <join>, and <link> gets a new
  name(s).

The new name for <alt>, <join>, and <link> might be one name so that
they can all be a member of a class, or it might be a different name
for each element so it can make sense semanticly. E.g.
  <alt alternans=>
  <join partialElements=>
  <link linked=>
(I don't really like those -- hope someone can come up w/ better names)


> Did the work group ever seriously consider getting rid of all
> IDREFS values and replacing them with child elements? It would be
> a pretty neat solution in most real-life cases I can think of.

The SO WG considered it, you & I have considered it, and IIRC,
Council has even considered it. The conversation stopper has always
been the same. I ask the question: "OK, what are we going to do with
the fact that *every* TEI element carries at least 5 attributes
declared as IDREFS (corresp=, synch=, exclude=, select=, and ana=),
and a whole bunch more carry decls=?" No one has ever come up with
any suggestion for how to handle all those attributes as children
(not to mention domains= of <linkGrp>, <joinGrp>, & <altGrp>; and
who=, which like target= has several instantiations that are URI and
several that are URIlist) at all, let alone how to handle them
elegantly.


There's probably more to say on this topic, but that's enough for
now.