John A. Walsh wrote:
> Some perceived advantages of this approach include:
> * formalizing the explicilty stated relationship between <rendition> and
> * encouraging more accurate and precise definitions of rendition
> for TEI documents.
Actually you're not encouraging, you're requiring.
> * avoiding loose encoding practices which allow, for instance,
> rend="italic", rend="italics", rend="italicize", etc. all in a single
But surely this kind of nonsense can and should be avoided using
DTD/schema customization, or other QA mechanism. It sounds to me as
though you would be requiring encoders/projects to do appropriate QA for
their 'rend' vocabularies -- which sounds reasonable, except that you're
dictating how it must be done.
Second: I would be very wary of closely coupling the source rendition
(rend attribute value) to the display specification. The purpose of
'rend' is, of course, to record what's in the source; how exactly that
gets displayed in the delivery system is a question for the delivery
system, which can/must change over time as technologies come and go, and
which often must account for multiple output formats.
Third: I see no reason why each and every instance document should carry
the definition of the rend vocabulary. The DTD/schema should control the
vocabulary, and the delivery system should handle translating those
values for on-screen display, document creation, etc.
> The major disadvantage of this approach is that it is not consistent
> with some existing practices and existing rend content. Of course, the
> issue of "breaking" existing documents/practice exists for many other
> changes in P5.
Breaking existing documents is certainly not the main disadvantage. All
documents break from P4 to P5, so that's a minor consideration.
University of Virginia