> So I think from a pragmatic point of view, while I agree that there
> should be a serious debate about this for P6, I'd really like to get
> your approval for including this proposal in P5, so that at least we
> have something for the purpose in P5. We will all be using P5 for years,
> and I think on balance it will be better for tool developers if we have
> something, rather than nothing.
I think this element is very important and I'm very seconding your
proposal of including information about applications in the TEI header
vocabulary. Applications should record themself in the header since since
it is necessary for processing the document with applications and since it
is a crucial information for the "interpretability" of the document.
However, I'm not convinced with some details of this proposal. For
instance, the list of possible attribute values for appDetail/@name is
very restricted. Of course, the list is open in this proposal. But I don't
think it should be hard-coded in the tei; but perhaps it should rather be
given only as exemple in the text. Other values may be as much justified.
Serge has enumerate several. It's depend upon the application.
I think the mechanism for expressing the "sectionTouched" (pointer) is not
as generic as required. It may be usefull for some application, but other
may prefere express the "sectionTouched" with TEI names of elements,
modules, or classes, for instance. Moreover one may want to express the
section an application *cannot* touch, in other to protect it, or the
sections required by an application but not created by it, etc.
In all this area we do not have too few experience for enumerating the
possible cases. Without this experience the proposal may be too strongly
coupled with one particular application needs. And the choice we make now
may reduce our capacity to do better latter.
The general argument "I need to have this piece of information (for
instance 'last saved' date) recorded in this particular place where it is
easy for my app to find it" is unsatisfing me. I agree that the TEI is too
complex to be used as a serialisation format -- and in fact it is not
design for that used. Applications cannot always rely on complex heuristic
and try to guess information amongst all the possible ways of encoding it.
But on the other hand, I think it is dangerous to redefine major pieces of
the existing header information (such as dating information, or encoding
rationale and choices) in a new place for the only reason applications
need more formal encoding. Should we have two places for encoding
versionning, one for human/traditionnal editing, the other for practical
access for application? We may surely found other way of coupling
different degrees of formalisation than defining everyting with two
The key point I think is that only the targeted application need to know
where is the information it needs. In fact, nothing implies that all the
information that applications needs should be recorded in one place, in a
"appInfo" section. Nothing implies neither than the enumeration of the
needs of applications should be from the responsibility of the TEI itself.
I think that the "appInfo" section should be restricted to only
registering applications with a name, a version, a description and an url,
and to associate an ID whith this description. All other information have
no well demonstrated reason to be here (in my point of view), and moreover
this minimal definition is all we can reasonably do with our current
I don't see why a general and flexible mechanism could not be imagine for
linking every existing parts of the header to an application requirement.
For instance, an application is interested in the last time it saved a
document? It is up to it to record an entry in revisionDesc, in a form it
may recognise latter, perhaps associating its ID with this entry. An
application need formally defined information about the meaning of an
element? It is up to it to add this formalism in the
encodingDesc/tagsDecl/tagUsage of this element. In fact I would be
interested in begining with an attribute, "app" for instance, pointing to
the id of an application registered in appInfo, added to "att.global" by
an "application" module.
[log in to unmask]
On peut pratiquer objectivement, c'est-à-dire impartialement,
une recherche dont l'objet ne peut être conçu et construit
sans rapport à une qualification positive et négative, dont
l'objet n'est donc pas tant un fait qu'une valeur.
Canguilhem, /Le normal et le pathologique/, p. 157
Ce message a ete envoye par IMP, grace a l'Universite Paris 10 Nanterre