[tei-council] TARGET/s and IDREFS attributes

[Lou Burnard]

Syd Bauman wrote:

>>I wondered about that.It seems very confusing to have the same name
>>sometimes mean one thing, sometimes several things, and sometimes
>>several things which are to be treated as one thing. Don't you
>>think it might be worth trying to rationalize them? (the old
>>target/targets was a half hearted step in that direction)
> 
> 
> 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.
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"/> 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; 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..."). 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 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>. So

<ptr target="#a #b"/> (discrete) becomes <ptr target="#a"/><ptr 
target="#b"/> (could be grouped into a <ptrGroup> if you like, or in 
some cases follow the suggestion for <catRef> below)

<ptr target="#a #b"/> (indiscrete) becomes
   <ptr target="#ab"/> <join xml:id="ab" targets="#a #b"/>

Mutatis mutandis, I think this applies also to <note>.

<catRefs> should probably be changed so that it has <ptr>+ content; this 
  might also be a sensible pattern for other things like the 
IDREFS-valued attributes in FS chapter to follow, except that I think 
that horse has already bolted.

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.

I'm CCing this to the Council in case anyone there has an opinion.

Lou