[tei-council] rendition, rend, and style

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

Dear John (cc Council),

For what it's worth, my instinct is to support only the pointer. As you 
note, it provides greater accuracy and clarity (much harder to have 
rendition values of "ital" and "i" with the same semantics in the same 
document if you've grouped <rendition> elements in one place), it can do 
everything that the inline spec can do and then some, giving a choice 
would just complicate processing and reduce interoperability, and if 
we're going to break existing practice, P5 is the time to do it.

Best,

David

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

More information about the tei-council mailing list