[tei-council] rendition, rend, and style

David J Birnbaum djbpitt+tei at pitt.edu
Thu May 10 14:19:00 EDT 2007


Dear John (cc Lou, Council),

Are you suggesting that @rend should always be a pointer to a 
<rendition> element, or that it should have the option of being either a 
pointer or an in-line specification?

Best,

David

John A. Walsh wrote:
> 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
>>>>
>>>
>>
>>
>
>
>




More information about the tei-council mailing list