Sebastian Rahtz wrote:
> Jon Noring wrote:

>> [Native support for TEI-Lite (or some other defined subset of TEI)
>> is being considered for the OpenReader format and for OpenReader
>> user agents.]

> I am not in a position right now to subscribe and get stuck into
> serious discussion; but can I flag the suggestion that we
> develop a _much_ tighter subset of the TEI than Lite for this
> sort of purpose? There has been some discussion about "TEI Tight"
> already (I am not sure where it has got to), and it would be good
> to have a stable target.

Thanks, Sebastian, for commenting upon the interest by OpenReader to
eventually support some subset of TEI, maybe within a future planned
"OpenReader framework" (similar to the OEBPS Framework, but with
better multi-vocabulary support and other improvements. Support for
TEI in the current OEBPS is somewhat difficult for reasons I won't
delve into here.)

> I would expect, for instance, a Tight schema to have no flexibility
> at all in the values for "rend" and "type" attributes,
> simplification of lists, simplified content models for <body> etc.
> Whether one would add syntactic sugar for readability, I am less
> sure (eg <oList> for <list type="ordered">) - probably not.
> As it stands, TEI Lite is a fairly serious pain to render easily
> and unambiguously.

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.

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.

For example, because OpenReader supports OEBPS (and OEBPS includes the
unique and powerful "out-of-spine" feature), it is now possible to
support "non-linear" content such as inline-placed notes and sidebars,
which TEI does have markup for. Currently, the HTML vocabulary has no
defined behavior for how to handle stuff, like notes, placed inline
(CSS can be used to move it out of the main flow, but that's messy,
and support for this in IE6 is horrible.)

An OpenReader user agent, for example, could remove an inline note
from the main flow and place it into a popup window or separate page
(similar to Microsoft Reader LIT handling of OEBPS out-of-spine
content.) (As an aside, it appears that XHTML 2.0 will add support
for inline-placed annotative material such as notes -- it'll be
interesting to see how quickly web browsers will add support for

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.

Other areas of interest with respect to "how could we do it in TEI"
include support for SVG, MathML and XLink. We are also focusing on
minimizing all presentational markup, so the "TEI-OpenReader" we are
looking for will be strongly structural/semantic.

I look forward to everyone's comments. I also encourage those here
interested in OpenReader, and eventual TEI support, to join the
'openreader-format' group at YahooGroups. We could use your help!


Jon Noring
OpenReader Consortium