[tei-council] rendition, rend, and style

Thu May 10 14:00:13 EDT 2007

I've been persuaded by David's position and his clear and strong 
distinction between descriptive and procedural/presentation.  I'm also 
persuaded that @rend should only refer to description of the source 
material (which may be the TEI document itself in the case of born 
digital material).  I still believe though in the benefits of changing 
@rend to be a pointer to one or more <rendition> elements which provide 
a fuller and more formal description of what exactly is being described 
in the source document.

John

Quoting David J Birnbaum <djbpitt+tei at pitt.edu>:

> 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
>>>
>>
>
>