On 6 May 2005, at 16:29, Jon Noring wrote:
> I'd be interested to know what aspects of TEI-Lite (and TEI in
> general) make direct rendering difficult (even if we were to
> augment CSS2/3 with a couple TEI-specific properties)? "Aspects"
> include elements, attributes, and content models.
I think the point Sebastian was making is that TEI Lite allows for a
wider range of possibilities than most implementors can hope to handle,
and that therefore most practical implementations have had to make up
their own rules of thumb as to what they will support. For example, TEI
defines a <list> element with a TYPE attribute, but only *suggests*
some values. This means that an implementor can be pretty sure what to
do with (say) <list type="ordered"> or <list type="gloss">, but may
well also be confronted by a <list type="frabjous"> or <list
type="potzbrje"> which the TEI Lite schema will happily accept. This
shocking liberalism applies even more to the notorious REND attribute.
TEI Lite is also pretty loose in its content models. You can for
example put a <label> anywhere at all, even within a <label>. So a
labelled list might appear as a sequence of <label> <item> pairs, or as
a sequence of <item>s, each with a <label> at its start. Or you might
find a <label> at the start of a <p>. These are all practices I have
witnessed in current applications of TEI Lite.
I'm curious as to what you mean by "direct rendering": from context it
appears you mean "using CSS to attach formatting properties to specific
XML constructs". There are quite a few TEI notions for which that won't
really hack it -- out of context <note>s is one. <divGen> is another.
And I'm none too sure about how you will handle conditional constructs
like the <sic / corr> janus elements, now replaced by <choice> in P5.
> One important point to note about OpenReader is that the planned
> reference implementation "OpenReader user agent" (some might call it a
> "browser" but we try to avoid using that term) is not going to
> restrict itself to the HTML paradigm.
Well, huzzah for that. But what will replace it? Something like FO
> TEI's table model is different than HTML's, so I gather, so that's
> another issue to deal with, but I don't see this as being major.
TEI has no table model to speak of -- it says tables are made of rows,
which are made of cells. And that's about it!
This is again something that implementors have difficulty with when it
comes to rendering TEI tables. It's an acute example of the basic TEI
design principle of representing *only* the semantics of the document,
and prefering to consider its appearance or rendering as a "simple
matter of programming"
From the Macmini at Burnard Towers