With a deadline to meet for an IMT release, I've had to make a decision,
and I made it in line with what Dot and I believed was the purpose of
@facs, and what I believe the guidelines actually say right now. As Alan
says, we have to trust the guidelines to some degree, especially when
there is disagreement among us. So the next version of IMT will use
@facs for all its links.
This might change in future, of course, if the guidelines change to make
the use of @facs more restrictive. That would have two consequences:
- Old IMT files would remain valid, because, whatever the ideal might
be, machines are never actually going to be able to discriminate between
different types of relationship; only humans can do that. Therefore
@facs will have to be available for <div>, and my what-may-be-deemed
tag-abuse will not result in invalidity.
- We'll have to come up with an alternative general-purpose linking
attribute for IMT to use.
The second of these is what bothers me. Ron and I were both under the
impression that @corresp is such an attribute, but an exchange a couple
of weeks ago with Lou on the list left us utterly confused about
@corresp too. I know that, in an ideal world, we would all have clear
intentions all the time, and even machines would be able to discern
those intentions. But in real life, especially in the realm of authoring
tools, that's not going to happen; we have to be able to use markup
structures which inherently vague and general-purpose in nature. There
are lots of such things in TEI; I'd say, for instance, that <div> itself
is one, as is <item> or <desc>.
So I would very much like a straight answer on @corresp, from as many
people as feel they have an opinion: is @corresp a general-purpose
attribute that makes no claims about the nature of the relationship
between two elements, or is it, as Lou seemed to be suggesting a while
ago, also indicative of a particular kind of relationship? And if the
latter, what kind of relationship?
If, in the long run, it turns out we shouldn't use @facs or @corresp,
then there's obviously a need for a generic attribute that makes no
claims about the nature of the relationship between elements. In that
case, I'd have to propose a new attribute (@rel, perhaps?), whose
function would be to link two elements the nature of whose relationship
is not known or knowable to the software or person creating the link.