[tei-council] rendition, rend, and style

Thu May 10 09:41:20 EDT 2007

This is both defensible and coherent as TEI policy. What changes are 
needed (if any) in P5 to reinforce that position?

David J Birnbaum wrote:
> Dear John (cc Council),
>
> In David's Magical World of Descriptive Markup, markup is never 
> procedural/presentational and output rendering is governed by mapping 
> descriptive markup to rendering details in a stylesheet. If I want my 
> code snippets output in a monospaced font, I tag them as <code> (or 
> something similar) and in my stylesheet (not my document instance) I 
> map the content of <code> elements to a CSS instruction to use that 
> font (or FO or some other stylesheet-level specification). I never 
> specify "monospaced font" as part of my markup of my born-electric 
> source.
>
> Similarly, I can't imagine specifying in my descriptive markup that an 
> element should be rendered as "big" in my output document. I might 
> specify that it was big in my source document (not the same thing, as 
> we've noted), or I might specify that it is important or that it is a 
> section heading, but if I want any of these three features to produce 
> rendering as big (however I interpret that) in the output, it would be 
> because "big in the source document" or "important" or "section 
> heading" was mapped to "render this in big type" in the stylesheet.
>
> I have no problem with mapping of @rend="big" to a font specification 
> in a <rendition> element when this is part of a description of the 
> source document. My only objection is to specifying output rendering 
> in the document instance.
>
> For what it's worth ...
>
> Best,
>
> David
>
> John A. Walsh wrote:
>> David,
>>
>> I agree about the descriptive vs. presentational issue...but the 
>> stylesheets you mention often need triggers in the TEI source, and 
>> they @rend attribute is often the trigger one uses.  Also, since we 
>> have an @rend attribute, it would seem useful to provide a standard 
>> mechanism for documenting how that attribute is used and defining the 
>> meaning of its content. @rend="big" could mean lots of things, but if 
>> it points to <rendition xml:id="big">font-family: Granjon; font-size: 
>> 16pt; font-weight: bold</rendition>, then one has a clear idea of 
>> what @rend="big" means, and this rendition definition may well refer 
>> to the source text, not any output format.  A stylesheet can still 
>> take the "big" trigger and do something else with it.  The Guidelines 
>> do already state that the content of rendition may be "expressed in 
>> running prose, or in some more formal language such as CSS."
>>
>> John
>> -- 
>> | John A. Walsh
>> | Assistant Professor, School of Library and Information Science
>> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
>> | www: <http://www.slis.indiana.edu/faculty/jawalsh/>
>> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh at indiana.edu>
>>
>>
>> On May 9, 2007, at 8:01 AM, David J Birnbaum wrote:
>>
>>> Dear John,
>>>
>>> Option C, please. XML isn't Microsoft Word and TEI markup should be 
>>> descriptive, rather than presentational. The ability to specify 
>>> output rendering is often very important to projects, but the place 
>>> to declare it is the stylesheet, not the document instance.
>>>
>>> Best,
>>>
>>> David
>>>
>>> John A. Walsh wrote:
>>>> Hi all,
>>>>
>>>> I'm supposed to write up my thoughts on proposed changes to 
>>>> <rendition> and @rend, including the possible addition of an @style 
>>>> attribute.
>>>>
>>>> The current P5 guidelines state that @rend "indicates how the 
>>>> element in question was rendered or presented in the source text."  
>>>> But my sense is that in practice @rend is used both to indicate how 
>>>> an element was rendered in the source text and/or how it should be 
>>>> rendered in a display environment such as a Web browser or printed 
>>>> output.
>>>>
>>>> The addition of @style could be used to distinguish between 
>>>> rendering in the source text (@rend) and rendering in an output 
>>>> format (@style). *OR* the addition of @style could be used to 
>>>> provided the @class/@style functionality of HTML.  @rend (like 
>>>> @class) could refer to predefined style classes, which could be 
>>>> defined in the <rendition> element of the TEI Header.  @style could 
>>>> be used to embed style information directly in an element.
>>>>
>>>> If we simply want to distinguish between source rendering and 
>>>> output rendering with the addition of an @style attribute, then my 
>>>> task is easy.
>>>>
>>>> If on the other hand we want to provide the @class/@style 
>>>> functionality of HTML, the task is more difficult and would involve 
>>>> prescribing or recommending practice that is not common at the 
>>>> moment, and would also likely involve changes to the <rendition> 
>>>> element and perhaps a new element in <encodingDesc> where folks 
>>>> could explain their implementation. For instance, users may define 
>>>> their styles using CSS, XSL-FO, rendition ladders, or some other 
>>>> mechanism, and this will need to be explained in <encodingDesc>.
>>>>
>>>> I believe we touched on all these various distinctions in Berlin, 
>>>> so I would like members of the council to weigh in on which way to 
>>>> go with this.  Please select A. or B. (or a new letter and proposal 
>>>> of your own invention):
>>>>
>>>> A. @rend/@style should distinguish between source rendering and 
>>>> output rendering.
>>>>
>>>> B. @rend/@style should distinguish between HTML-like @class 
>>>> functionality and HTML-like @style functionality.
>>>>
>>>> Incidentally, if we go with B. and style classes are defined in 
>>>> <rendition> elements of the TEI Header, then we could add an 
>>>> attribute to <rendition> that indicates whether the "target" of 
>>>> this rendition "class" is the source text or the output format.  
>>>> The @style attribute would remain ambiguous in terms of 
>>>> source/output, but this ambiguity could be addressed and clarified 
>>>> in the <encodingDesc>.
>>>>
>>>> Once I hear back from others on the Council, I'll proceed with a 
>>>> more formal document on this topic.
>>>>
>>>> John
>>>> --| John A. Walsh
>>>> | Assistant Professor, School of Library and Information Science
>>>> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
>>>> | www: <http://www.slis.indiana.edu/faculty/jawalsh/>
>>>> | Voice:812-856-0707 Fax:812-856-2062 <mailto:jawalsh at indiana.edu>
>>>>
>>>>
>>>> _______________________________________________
>>>> tei-council mailing list
>>>> tei-council at lists.village.Virginia.EDU
>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>
>>
>> _______________________________________________
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>