I have just read through that interesting thread.
If I summarize well there were suggestions
to place xslt declarations at the following
different places :
- encodingDesc (David, Wendel)
- encodingDesc/appInfo (James)
- encodingDesc/tagsDecl/rendition (Sebastian, Dot)
- profileDesc/settingDesc (Torsten)
- @rendition of either TEI or teiCorpus (Bertrand)
- Processing Instruction (James)
Binding xslt stylesheets to a document is needed
for the following purposes :
- 'the XSLT is necessary for the "correct interpretation"
of the document'
- "[define] how a born digital document should be presented"
-"[define] which xslt has to be applied to show the content
in a certain and defined way"
- "Recording a stylesheet seems to [be] more general than
the view of some portions of text"
If we consider that XSLT is very general, that is
it can express *any* transformation of the document,
for the purpose of producing a new version of the document,
or for its display (rendition : HTML, PDF...), or search and
count (give me the list of all tags used with their frequency),
etc. it may be interesting to relate it to all processing tools,
or more simply to 'tools' or 'applications'.
This could be regardless of the intended usage of the tool
(document a semantic aspect, finalize a structure, etc.) for
the same reason that if Oxygen was used to edit the document,
which could have a trace in an appInfo element, the intended
usage of using Oxygen is documented precisely somewhere
else in the encodingDesc element.
To encode processing context information, it may be interesting
to create a new element in the TEI Header, called for example
'processingDesc', sibling of the four *Desc 'context' elements,
to handle all information related to processing context - before
or after the moment you read the document. We could then put
appInfo and rendition there.
If we generalize appInfo a bit to deal with any processing tool,
and not only XML editing tools, we could also handle
XSLT stylesheet binding by saying something like :
<application version="18.104.22.168" ident="SaxonB">
<param name="stylesheet" url="foobar.xsl"/>
<param name="treemodel" value="standard"/>
Maybe this is too precise because any XSLT processor could do
(but we could also express a virtual generic XSLT processor).
Of course, this encoding doesn't tell if the stylesheet was used,
or should be used prior to something, etc. But it is general and can
encode usefull (mandatory, tuning...) parameter informations for the
tools intended to do something with the document. For example a
param element could point to an Oxygen sample preference file.
About embedding the stylesheet in the document, it is always
possible to use the binaryObject if it is not possible to change
the namespace (like for svg embedding for example).
---- Original Message ----
From: "Wendell Piez" <[log in to unmask]>
> I'm sympathetic to
> Gabriel's answer of encodingDesc. The implication of the requirement
> is that the XSLT is necessary for the "correct interpretation" of the
> document: that is, that the semantics of the document markup are
> actually specified in the XSLT (and in the transformation results),
> over and above what the tag set implies or the TEI Guidelines say.
Dr. Serge Heiden, [log in to unmask], http://textometrie.ens-lsh.fr
ENS-LSH/CNRS - ICAR UMR5191, Institut de Linguistique Franšaise
15, parvis RenÚ Descartes 69342 Lyon BP7000 Cedex, tÚl. +33(0)622003883