I'm very convinced of the usefulness of this piece of information and
would use it myself, I'm only feeling that this solution is too much
defined for one particular tool and situation.
For instance, I'm not sure that the different things/needs shouldn't be
1) documenting the fact that some piece of the markup is produced by a
specific tool, or more generaly that such tools as been used in such
condition, as you said (encodignDesc)
2) allowing an application, when it processes a document, to put somewhere
a "log" of the modification it done; the revisionDesc looks more usefull
3) providing information for an application to be able to decide if the
encoding of the document it processes satisfies its own condition; it
could perhaps be done with the more general previous points.
> The "last saved" date is important because if we envisage multiple
> applications working on the same file, it will be very useful for
> those applications to know that another application has worked on
> the file recently.
I agree, but I think this is different from the recording of an
application in the encodingDesc part, and that the mechanism for encoding
this two information may be different. Why not an attribute "app" on
element in revisionDesc?
> as I said, I don't particularly mind where it goes, as long as it
> goes somewhere specific in the header, and is kept as a block so
> it's easy for an application to find and read.
You make clear something: there is something strange in this request of
being "easy for an application to find and read", in the sense that the
TEI *is* supposed to be "machine-readable" as a whole. Of course "machine
readable" is different than "usable as a serialisation format by an
application"; but I think that a benefit of the TEI is to keep as strongly
coupled as possible both aspects, trying to do as far as possible the
whole TEI vocabulary usable as a serialisation format.
I found very interesting a mechanism for associating some part of the
encoding with an application (as you propose in point 4 on FS proposal),
so that other application are not supposed to touch it; but perhaps we
need a more generalist and robust method. The mechanism proposed is quite
restricted: "A list of identifiers pointing to elements in the file which
the application has edited.". Why not declare element name (or a TEI class
of element) as belonging to an application? and allowing to claim
ownership of an element in the text of a document (with an attribute "app"
globally available on element for instance)? Perhaps this question need a
whole "classe" in the TEI sense.
> I don't really understand how it violates the meaning of the header --
It looks strange to me in the sense that a temporal
information goes into encodingDesc and not into revisionDesc.
The proposed element if I understand correctly is precisely *between* the
encodingDesc and the revisionDesc purpose: as a dated modification of the
document, it should belong to the revisionDesc, but as the product of a
tool, potentially redefining the meaning of the markup (particularly from
the point of view of another app), the encodingDesc element is interested.
The TEI header does not (correct me if I'm wrong) really authorise the
meaning of the encoding to be "dated". Such a "date" is what is produced
when the TEI is a serialisation format common to **several** applications.
In the situation we speak about the TEI is not just the serialisation
of one application, neither an human annotation, but a
partially-serialisation format for several application. I found this
interesting from a corpus linguistics point of view.
> These are the four reasons on the SF proposal:
> 1) to allow an application to discover that it has
> previously opened/edited a file, and what version of
> itself was used to do that;
> 2) to show (through a date element) which application
> last edited the file to allow for diagnosis of any
> problems that might have been caused by that application;
> 3) to allow users to discover information about an
> application used to edit the file;
> 4) to allow the application to "declare an interest" in
> elements of the file which it has edited, so that other
> applications or human editors may be more wary of
> making changes to those sections of the file.
> I think only the second is strictly temporal information, isn't it?
I was perhaps misunderstanding the "previously" in the first point and the
past tense in the third.
Finaly I agree that there is a need for an annotation mechanism for
application, but I'm only feeling that this solution is not very generic
[log in to unmask]
Ce message a ete envoye par IMP, grace a l'Universite Paris 10 Nanterre