Perhaps we're slightly struggling with this discussion because some of
us are familiar with the IMT and how it tends to be used, and others
aren't; a lot of the replies have been based on erroneous assumptions
about what it's for and how it's used. Here are two different examples
of how I've used it.
The first is an engraving from the Mariage project:
There are four categories of "annotation" here:
Transcription de texte
Commentaire sur les gestes
Liens aux textes
Graveur ou bibliothèque
In more recent work which isn't yet online, there are also "Objets" and
The second is an interactive screenshot from the tutorial for the IMT
Here, the categories are:
Controls for file operations
Controls for editing metadata
Controls for creating and deleting annotations
Controls for categories
Controls for creating the Web View output
In the first example, one category is clearly transcription (although
for the application to understand this automatically, it would have to
have some AI capabilities in French). The other categories don't
necessarily easily lend themselves to <note> or <div> discrimination,
although "Liens aux textes" have embedded notes in them which link to
other texts; sometimes they have more than one such embedded note.
In the second, all the categories are expository or explanatory -- this
is software documentaion, after all -- and you might argue that they're
all <note>-type annotations. However, the software cannot possibly
figure that out, and the user is only interested in grouping the
software controls into different types based on function, not in
deciding how this might map to the TEI.
To try to get the user to discriminate, at the point where they add or
edit an annotation, between the different possible TEI renderings of
their content would be rather like asking a Word user, when they press
the Enter key, "What kind of paragraph are you writing, then?
Introductory? Expository? Narrative? Persuasive? Make up your mind!"
It's not going to work. So I do need a single structure which will cover
all possible use-cases.
I think it's a <div>, and nothing I've read so far has convinced me
otherwise, I'm afraid. The question is whether @facs, or some other
attribute, is the appropriate way to link that <div> to a <zone>. Again,
so far, I'm with Arianna and Dot in believing that @facs is the one,
because of how I understood the original FACS proposal, and how I now
interpret the guidelines.
Both Lou and Conal argue that the guidelines either shouldn't be
interpreted the way we interpret them, or that they don't say what they
should say (in other words, they don't make clear something which was
intended by the FACS proposal). In that case, fair enough: change the
guidelines to make it explicit that @facs is intended only for linking
transcriptions and nothing else. If I'd thought that was the intention
when we were discussing the original FACS proposal, I would have argued
against it, though; both Dot and I had a different view during our
discussions of FACS, and I think our view is reflected in the guidelines
as they now are. And in that case, please suggest another attribute I
can use instead to link a <div> to a <zone>; would it be @corresp?
I'm hoping to get the new version out by Christmas Eve :-)