[tei-council] More on rend
Daniel O'Donnell
daniel.odonnell at uleth.ca
Fri May 11 12:15:00 EDT 2007
I think if there has been a trend throughout our P5 council discussions
it has been towards purity. So I'm happy with how things are going.
On Fri, 2007-05-11 at 07:01 -0400, John A. Walsh wrote:
> 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>
>
>
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
--
Daniel Paul O'Donnell, PhD
Department Chair and Associate Professor of English
Director, Digital Medievalist Project http://www.digitalmedievalist.org/
Chair, Text Encoding Initiative http://www.tei-c.org/
Department of English
University of Lethbridge
Lethbridge AB T1K 3M4
Vox +1 403 329-2377
Fax +1 403 382-7191
Email: daniel.odonnell at uleth.ca
WWW: http://people.uleth.ca/~daniel.odonnell/
More information about the tei-council
mailing list