[tei-council] rendition, rend, and style

[David J Birnbaum]

Dear Lou (cc John, Council),

We might want to review the description of @rend in the guidelines to 
ensure that the TEI recommends that it be used to indicate rendering in 
the source document, but not to specify output rendering. Since new 
users will then ask "so how do I specify output rendering?", we might 
also add a note that output rendering is governed by associations in 
stylesheets between the descriptive TEI markup and the desired output 
final form, and that output rendering is not specified in the document 
instance. If we are feeling ambitious, we can point them to a discussion 
in the Gentle Introduction of the difference between descriptive and 
procedural/presentational markup as away of explaining why specifying 
output rendering in the document instance is a Bad Idea (that is, why 
the TEI isn't supposed to be a typesetting spec).

If we need an example, John and I discussed a specific issue from his 
projects in private email yesterday, and he's welcome to introduce that 
into the discussion if he thinks it would be constructive.

In other words, I think the current TEI syntax is probably fine, and we 
just need to make sure that we provide clear advice about the semantics. 
We may already do that.

Best,

David

Lou's Laptop wrote:
> 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
>>
>