[tei-council] rendition, rend, and style

[John A. Walsh]

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

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

I think this question is now the major issue we have left to tackle.  I 
would argue that we need to decide one way or another, rather than 
providing an option.  Of course, we need a datatype on @rend, and I 
don't think there is one that would accomodate both pointers and inline 
specs.  I think people understand the advantages of the pointer system. 
  We end up with a tightly coupled system of <rendtion> elements and 
@rend pointers, which provides, I think, more accuracy and clarity, but 
it's a bit more rigid and more complicated.  It also breaks a lot of 
existing practice.

With all this feedback, I believe I can write up some useful 
clarifications for @rend, but do we simply clarify existing usage or 
propose a more radical change?

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