[tei-council] More on rend

[John A. Walsh]

Hi all,

Yesterday David mentioned a private exchange we had about a specific  
example of rend usage.  The example is somewhat analogous to the  
interpretive categories issue we discussed yesterday and provides  
further amplification to David's thoughtful commentary on the issue  
of descriptive vs. presentation/procedural markup.  The exchange is  
less relevant to the specific discussion of rend as pointer to  
<rendition>, so I don't want the message to confuse that issue, but  
here it is for your enjoyment:

> From: 	  djbpitt+tei at pitt.edu
> Subject: 	Re: [tei-council] rendition, rend, and style
> Date: 	May 9, 2007 10:31:45 PM EDT
> To: 	  jawalsh at indiana.edu
> Reply-To:  djbpitt+tei at pitt.edu
>
> Dear John,
>
>> I'm wanting to succumb to the rigorous purity of your descriptive  
>> vs. presentational distinction, but find I've perhaps irrevocably  
>> polluted my own personal encoding practice.
>>
>
> The purity of which you speak is a hypothesis I am continually  
> testing, but so far I haven't run into trouble. When I really need  
> to focus on a specific output format, I use Word or PowerPoint or  
> presentationally-oriented HTML. When I want to focus on structure,  
> I use XML with descriptive markup and impose presentational  
> features during XSLT transformation. So far I've been able to  
> maintain my principles and get the results I need.
>
> [By the way, concerning purity and principles more generally, I may  
> have mentioned that one of the first papers I ever delivered at an  
> SGML conference was entitled "In Defense of Invalid SGML," where I  
> told several hundred people who write massive electronic  
> documentation files for government and industry why it might be  
> desirable to produce SGML that failed validation. I got a laugh  
> when I said "I'm an academic; I don't have to build working  
> systems," but the paper was serious, and I hope I dealt seriously  
> with the consequences. (If you're curious, the paper, with a less  
> polemical title, is at http://clover.slavic.pitt.edu/~djb/sgml/ 
> invalid.html .)]
>
> In any case ...
>
>
>> Here's an example.  My documents are full of <persName> elements.   
>> In some cases, I want the <persName> element "rendered" as (or  
>> with) a mouseover gloss that describes a potentially unfamiliar  
>> person.  So <persName key="bill">William Shakespeare</persName>  
>> may not need a gloss, but <persName key="villon">François Villon</ 
>> persName> may indeed need a gloss.  I've done something like this,  
>> <persName rend="gloss" key="villon">Fraçois Villon</persName>.   
>> What other semantics (other than @rend) are available to me to  
>> make the distinction between names needing a gloss?  Perhaps my  
>> person database could contain a field indicating whether the  
>> person requires a gloss. But I may be using the same database for  
>> multiple projects and multiple source documents, and the need for  
>> a gloss may not be consistent across all these projects/documents.
>>
>
> I like the syntax of your solution, but I would approach the  
> semantics differently. Instead of @rend="gloss" I would have  
> something like @unfamiliar="yes". The descriptive fact is that the  
> name is unfamiliar, and the way you deal with it in one view is to  
> provide a mouseover gloss. You might, in an alternative view,  
> render all of the unfamiliar names in a different color and ask  
> your students to identify them for a test, and in that view you  
> wouldn't be glossing them at all. Or you might collect a list of  
> unfamiliar names as an appendix for scholars or a study guide for  
> students, with or without glosses. In other words, the  
> unfamiliarity is the descriptive fact, and the glossing an artifact  
> of a particular view. Both of our approaches tag the unfamiliar  
> names, but mine separates the fact that they are unfamiliar (and  
> therefore might need special treatment, with the exact special  
> treatment subject to variation) from the way they are rendered in a  
> particular view / application / environment.
>
> Another approach might be assemble the information about who gets  
> glossed for a particular project not in your general database of  
> persons (since the need for glossing may vary from project to  
> project) and not in the <persName> elements in the document  
> instance, but in a separate structure in the header in the document  
> instance, one that listed the names that should be considered  
> unfamiliar within the context of that instance. This has the added  
> advantage of letting you indicate once in the header that every  
> occurence of François Villon should be considered unfamiliar in a  
> particular document without having to add the @rend element each  
> time the name occurs.
>
>
>> Without taking up too much more of your time, could you offer some  
>> advice on this particular case?  It's something I've been  
>> wrestling with, and I would value your input.
>>
>
> I'm happy to spend time this way. And, unlike with my invalid SGML  
> presentation, I think the approaches described above should be able  
> to maintain markup that is rigorously descriptive while also  
> providing a working system that affords the functionality needed  
> for the projects you describe.
>
> Does this help?
>
> Cheers,
>
> David




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