>>> What the TEI can do, IMHO, is only to provide a mechanism for the
>>> application to ask the user for information. For instance, a
>>> mechanism thanks to which the application can define a way for user
>>> to tell which element should be used as sentence boundary.
> But suppose that we are at the moment when the user has already answered
> the questions you mention to the application. Wouldn't it be possible to
> encode the answers in the document itself for later reuse ? isn't it 
> the  role of a "processing parameter" ?

Yes, by "provide a mechanism" I was meaning "provide a markup 
mechanism": a way for the user to express parameters in the document, 
or for the application to record parameters in the document.

>>> I don't see why tagUsage cannot be the natural place for storing more
>>> formalised structures an user could use to tell an application the
>>> usage it should do of tag.
> The question here is not the one of formality of description, it is 
> only  that tag names alone are not sufficient to be the unique entry 
> points for an
> application to be told how it should process a document. This comes
> from the fact that the data model of an application for a text is often
> not the same as the TEI data model for a text.

I don't understand.

>>> Rendition is not really a precisely defined element. It is a
>>> placeholder (a "hook" say the Guildelines) for expressing thinks the
>>> TEI is not responsible of.
> This is a rather strange statement.

Why :-? I said that the TEI has not defined itself as responsible for 
providing a markup for encoding rendition, but for providing a markup 
for encoding "textual features". Thus, there is no precise mechanism 
defined for expressing rendition, appart the element "rendition" 
itself. So, if "rendition" if a sibling of tagUsage, isolated, it is 
precisly because it is not included in the TEI. I'm not sure it is what 
we want for application parameters.

> If we expect applications to be "responsible" for particular
> treatments of documents, based on specific encodings, it would
> be nice if those encodings could be a minimum "precise"
> or expressed with minimum "responsibility".

Of course.

>>> The discussion is about coupling a format intended to human-oriented
>>> annotation with processing tools which need a serialisation format.
> I think this is the point where we disagree. For me, encoding 
> represents  a contract between humans about the interpretation of a 
> text AND represents
> a contract between humans and machines about the interpretation they
> should share for the things they have to do together : that is text  
> interchange
> between humans AND machines. If TEI is only for humans, I am afraid
> we will not be able to built useful software for TEI texts.

I don't disagree with that. And it does imply that the TEI is different 
from the ODT format, since ODT does not imply interpretation at all.

I would be interested in hearing your opinion about the alternative I 
proposed, between defining an encoding of application parameters common 
to all application, and defining a markup mechanism that each 
application used for expressing its parameters in its own way. Do you 
think that it make sense to propose this as an early choice to do for 
defining this markup area?

thanks for this discussion
Sylvain Loiseau
[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