Perhaps as one of the editors of the original xhtml recommendation, and of
the xhtml modular recommendation I could make a few points.

xhtml was only intended to be another XML document type, suitable for
producing simple documents for presentation on the web. It was always
understood the Document types such as TEI or Docbook would be used for
complex presentations. 'div' and 'span' elements, together with their class
attribute was introduced specifically to allow the conversion of  more
complex document types, such as TEI, to xhtml while still producing valid
xhtml documents. It was recognized that the semantics were not ideal, but
one of the requirements of xhtml was that it was to be a 'lingua franca'
usable by most users.

The idea behind xhtml modules was that with or without the use of
namespaces, xhtml fragments could be incorporated into other document types
and it was specifically noted that this would produce a _NEW_ hybrid
document type neither the original or xhtml. So go ahead and create a hybrid
of xhtml and TEI, but do not call it a TEI or xhtml document type call it by
a new name.

The beauty of  TEI, as discussion on this list shows, lies in the semantics
of the elements, and it's ability to mark up truly complex documents.

In my paid work I use either DOCBOOK or hand-rolled schema's (I work with
highly technical engineering and scientific documents) and use XSLT to
convert to xhtml for web presentation. For my hobby I use TEI to mark up 2nd
and 3rd C Greek and Aramaic documents, and again use XSLT to transform to
xhtml. In both cases I prefer to NOT create a new document type, but to
stick with the old. The semantics are contained in the original document
type, the presentational aspects contained in the XSLT stylesheet that I use
for transformation to xhtml.

Certainly 'bastardized' TEI/xhtml documents are going to work in browsers
(because the default is to ignore elements they do not recognize) and IE
will even give a reasonable display of a 'blockquote' inside a 'p' (because
the default is present well-formed xhtml, not valid xhtml), but that does
not mean that we are doing the right thing. Browsers assume that EVERYTHING
with an .html suffix is either HTML or xhtml. If you use the .xml suffix
they will look for a style-sheet, and failing to find one will usually
display a 'tree' presentation. (One of the few things IE got right:>))

TEI, xhtml, Docbook are just some of several thousands of XML document
types. As with any craft, in document work the trick is to use the right
tool for the job.

Frank

Frank Boumphrey
(Latest Book co-authored 'XML.NET Developers Guide' from Syngress Press by
Sills, Boumphrey and Ortiz)



----- Original Message -----
From: "Daniel O'Donnell" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Wednesday, February 09, 2005 7:56 PM
Subject: Re: A new type of TEI-Lite?


> Once last question on this topic.
>
> Accepting the point that a teihybrid composition language might
> encourage people to develop bad habits and start writing for browsers,
> what if we instead saw the the idea of a hybrid tei/xhtml as a solution
> to the original xslt question.
>
> 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? 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.
>
> 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.
>
> Again, I can see objections: are we not running the risk of starting
> browser wars again? What if people develop better browsers? What about
> accessibility issues? 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.
>
> -dan
>
>
>
>
>
> Wendell Piez wrote:
> > Hi Daniel,
> >
> >
> >>Seriously though, I guess I was also thinking of the suggestion in P4
that
> >>one create an URL attribute for pointers in order to handle, well, URLs.
I
> >>thought it was an elegant solution.
> >
> >
> > It is not inelegant. It provides TEI users with a way of asserting a
tight
> > binding to a nearly universal application semantic, which they expect.
We
> > are still free to implement more robust solutions using various kinds of
> > indirection, if we want to maintain the overhead (unparsed entities,
> > anyone?). So nothing is lost but our innocence, even if it does violate
the
> > strict principle I was trying to assert.
> >
> >
> >>The question of whether a hybrid might be an answer came up today as I
was
> >>writing an article in TEI (because it handles notes and pretty much
> >>everything better) that needs to go out in HTML. When I came to a
> >>blockquote within a paragraph followed in the next by a figure and began
> >>to ask myself if I should just be writing the thing in xhtml.
> >>
> >>I have lots of quick an dirty documents I work on where I would like the
> >>benefits of both worlds. I realise, of course, that it is a simple
matter
> >>to build a basic tei>xhtml stylesheet or modify an existing one, but I
> >>find I'm always having to do that and this time wanted something in
> >>between to check my work as I was composing. While Firefox was working
> >>fine for most of the time, a hybrid would be useful for the complicated
bits.
> >
> >
> > I *really* sympathize with this: pondering where the best break is
between
> > hacking/fudging/making-do, and engineering something stronger, is how I
> > spend my days.
> >
> > FWIW, I can report (nor am I the only one) that investing the time in
> > developing your own authoring tag set (profile of TEI or not) is well
worth
> > the effort, if you are not unhappy about spending your days with XSLT
for a
> > while. These days, my own authoring tag set needs only very rare
> > interventions to extend it or to implement new features, and by now I
have
> > transforms to convert it into HTML, DocBook, the Extreme conference DTD,
> > and TEI ... about the only major target I haven't gotten around to is
> > XSL-FO (think of that: and yes, I do have a stylesheet that draws an SVG
> > "plot" of the document). This is after several years of development, but
> > during no period has it demanded anything close to full time.
> >
> >
> >>I suspect the namespace or extensions root might be the way to go. If I
> >>called it dirty, I'd not be tempted to use it in real projects.
> >
> >
> > And in the process, you might discover something really clean and
sparkly,
> > hidden inside.
> >
> > But we have come an enormously long way. Stories like James's are
> > inspiring. When students can look at the toolset, see *through* it at
what
> > it's doing, see the XML piece, the XSLT piece, the CSS piece, make a
tweak,
> > see it work, say "oh cool, it works" -- this is very very far away from
the
> > old days of "some day, we'll have tools that do X and Y and Z".
> >
> > Cheers,
> > Wendell
> >
> >
> > ======================================================================
> > Wendell Piez                            mailto:[log in to unmask]
> > Mulberry Technologies, Inc.                http://www.mulberrytech.com
> > 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
> > ======================================================================
>
> --
> Daniel Paul O'Donnell, PhD
> Associate Professor of English
> University of Lethbridge
> Lethbridge AB T1K 3M4
> Tel. (403) 329-2377
> Fax. (403) 382-7191
> E-mail <[log in to unmask]>
> Home Page <http://people.uleth.ca/~daniel.odonnell/>
> The Digital Medievalist Project: <http://www.digitalmedievalist.org/>
>