At 07:56 PM 2/9/2005, Daniel wrote:
>In other words, going back to the original question raised about
>transforming tei paragraphs containing blockquotes or lists to non-valid
>xhtml: what if we decided to transform our tei to an output that was
>well formed, but something between tei or xhtml?

Why not valid?

Liberal use of divs with class attributes, plus nesting, would allow us to
reconcile semantic views, I think.

It's true that with structures like:

<div class="tei-p">
   <p class="renditional">...</p>
   <div class="tei-q">...</div>
   <p class="renditional">...</p>

not all the "true" semantics of the relations could be validated with DTDs
or RNG (I don't think RNG can trigger content models off attribute values,
can it?), but looser regimens such as Schematron could establish, at least
to an extent, where it went off track.

In the meantime, this can be valid XHTML.

What is still not fully clear to me is what the intent of this proposed
language is. Is the goal to provide a browser-friendly TEI version or
subset that would display cleanly without transformation, using just CSS,
in a CSS-compliant browser? Or is the goal to provide a "clean target" for
(simple) transforms, an XHTML or near-XHTML that better preserves the
nominal semantics of the original?

These are two very different things.

>  This would allow us to
>keep the tei structure for the blockquotes within paragraphs (since tei
>seems to have a better structure here) and convert to xhtml for the
>operational things that the browsers prefer (I realise this
>'operational' category is something I'm creating and that they are
>really structural: but I'm thinking about them from a browser
>perspective). The result would be a structural language that would load
>in browsers while keeping the essential tei structure intact.

But this accepts the necessity of a transformation step -- it's not the
simple authoring language that was being discussed earlier.

(Note: even in the best of cases people will often want a transformation
step anyway, to handle things like footnotes and ToCs -- two of the best
reasons to author in XML.)

>I suspect the elements that would need transformed are pretty
>straightforward and relatively few, and that changing them would have
>little effect on the larger tei document structure. The result would
>have the advantage of doing frankly what we are all really doing
>secretly with our xhtml conversion: transforming the tei to what is
>actually intended to function as a browser language.

Hey if it's a secret, no one told me!

>Again, I can see objections: are we not running the risk of starting
>browser wars again?

I'm not worried about that. We should stay standards-compliant whatever we do.

Deploying a tag set that doesn't make false claims about what it is doesn't
require breaking standards.

>  What if people develop better browsers?

They will (and again, back to standards).

>  What about accessibility issues?

Yes, what about them? :->

>  My point, however, is simply that a hybrid output
>may avoid some of the structural translation issues we've been seeing.
>At the very least, it might result in simpler stylesheets.

Again, the question recurs as to what this is really intended to do.

I'm actually reluctant to go into a design phase to address a problem that
is at its root the ugliness of a certain kind of transformation in XSLT
1.0. I'm able to be an honest proponent of XSLT in part because I don't
accept that the capability of tools should drive design (except for
one-offs, where the design can be tossed afterwards: a different matter).
Particularly in this case, given how:

* Several solutions to the nasty transformation problem are known, and can
be documented on a wiki;
* XSLT 2.0's grouping constructs should make this transform easier in any
case. And eventually, XSLT 2.0 should become a W3C Rec, at which point we
may see more uptake, more widely-available tools, etc. etc.

Nonetheless, if that mini-upconversion required to bridge the gap between
views of a document that are logical (a blockquote is "inside" a paragraph)
and renditional (a blockquote splits a paragraph in two, requiring the
content on either side to be grouped)  is really that much a point of pain
... I don't think that deploying a hybrid language would be evil. It can't
be called XHTML, but that's okay. Neither should it be called "TEI",
however, I don't think, since (as I argued yesterday) that really muddies
what TEI is all about (semantics that are "intrinsic", not
application-oriented, to the extent that goal is meaningful and possible).
But that's a somewhat different debate.

Asides: I found Peter's post about XUL to be very stimulating. I don't
think going Moz-only is necessarily a good idea, at least for the TEI
generally (staying neutral in these disputes between superpowers may be a
good idea even if you know what side you're on, if only to maintain better
contacts with those still working behind the wall) -- but I do believe that
the XUL direction is promising, that standards in this area (XUL vs the MS
variant, which I suppose will be XAML? and where will Safari go?) will be
both important and hard-fought (yes, this is the browser wars over again),
and that any activity we show in the way of demonstrations of what's
practical could be widely useful and a real contribution.

I also found Frank's post clarifying the "intent" of XHTML to be very


Wendell Piez                            mailto:[log in to unmask]
Mulberry Technologies, Inc.      
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
   Mulberry Technologies: A Consultancy Specializing in SGML and XML