Re: [Texmacs-dev] HTML, XML, XSLT (was: texmacs installation problem)

[Joris van der Hoeven]

> I do not want to be rude by barging in on your discussion, I just want
> to chip in and add my 2 cents. So, here are some opinions of mine:
> 
> 1) Writing a good HTML filter may be *more* difficult than writing a
> simple TM->XML filter and converting XML to HTML via XSLT. 

In my opinion this is just moving the problem: raw XML is just a data
format, really nothing more than a scheme expression, and vice versa.
So we need something to rewrite TeXmacs trees into HTML, whether you
represent those trees by an XML file and use XSLT or by directly
using scheme. The latter has my strong preference, because it is
more powerful and less verbose than XSLT.

> You want your website and your documentation to have a consistent look
> and feel. That means, you will *not* want all the flexibility of TeXmacs
> to be brought to bear on your website. This does not mean you want your
> website to look simple: you want your website's content to stick to a
> simple, abstract structure which generates a good-looking consisten
> webpage-layout. However, writing a good HTML filter means writing a
> filter that maps _as much as possible_ of what you can do with texmacs
> _as precisely as possible_ to HTML. These are two different goals and
> "abstraction" may be easier to implement than "imitation". 

Yes, but the "as much as possible" is really "just what is needed for
the webpages" at a first stage.

> 2) A filter that generates an entire website from TeXmacs documents
> *directly* is less useful to most users than one that generates XML in
> between. 

Once again, raw XML is not that useful, except that certain people
are just happy to see the label "XML". One may for instance use David's
program to generate XML.

What would be more useful is having precise DTD's and tools for
these DTD's, such as conversion to other DTD's. However, it is not
clear whether it is a good thing to do conversions concerning *TeXmacs*
documents (in contrast to conversions between Docbook, HTML, FO or
whathever for which there are already programs) on the XML side:
once again, Scheme is more powerful than XSLT. My bet would rather
be to be able to represent XML documents inside TeXmacs and
have tools which use Scheme instead of XSLT.

> In theory the content of a webpage is kept in a HTML-file (and only
> there) and the layout/look is kept in a CSS-stylesheet (and only there).
> In practice this is rarely the case. Most of the code HTML files contain
> is related to layout: tables to position and color news-boxes, sidebars
> and menubars, little pieces of images that make up one big image even
> though the <img> tags appear at totally unrelated places in the HTML,
> etc... Give or take preferences of visual design a) most people want
> this control when designing their webpage. b) People still want to
> seperate content from layout. c) People want an individual look&feel for
> their own webpage. Some use PHP, ASP, Perl or Zope to achieve these
> purposes. Some [1][2] use XML & XSLT. 
> If you write a HTML filter that is good for your site, you require
> people who want to use it for their own site to customize _that filter_.
> If you write an XML filter and XSLT-stylsheets to other common XML
> dialects, they only need to provide a custom stylesheet. 
> 
> For more on the advantages of XML+XSLT->HTML over direct HTML see 
> [1] http://www-106.ibm.com/developerworks/library/us-gentoo/index.html
> [2] http://www-106.ibm.com/developerworks/usability/library/us-gentoo3
> 
> Of course a thorough XML solution that e.g. properly integrates SXML
> into TeXmacs is a big effort. What I rather propose is a simple TM->XML
> export filter that maps the TeXmacs document tree more or less 1:1 to
> XML. I have written a *very* basic version of such a filter. This XML
> representation might then be mapped to HTML or to some other
> intermediate format. If have implemented such a XML->HTML scheme for
> this [3] site and we have been very successful with it. It also includes
> a meta-transformation to generate the entire site w/ navigation in a
> single step.
> 
> [3] http://www.pfh-schulen.de
> 
> However, there remain quite a few problems with XML-export:
> 
> A) Conversion of character encoding. This would have to be implemented
> for a direct-HTML-solution as well?

Yes, I think that we should start by paying more attention to
this kind of stuff. In any case it is good to have a reliable
correspondance with raw XML. Spending a weeks on character encodings
seems an annoying but necessary prerequisite to me.

> B) How should document/concat nodes be handled? To always include them
> in the XML tree, is rather verbose and probably makes XSLT-stylesheet
> creation more difficult. This may be a deeper problem that cannot be
> overcome easily.

Yes, and there are many more such things if you want to do things
in the "XML-way": with, formatted tables, etc.

> C) How to handle TeXmacs macros like section*? The <section*> is not
> proper XML. <sectionstar>, however, is ambiguous.

Are there some escape characters allowed in XML?

> So direct HTML export may yet be the better option.

That is what I think: please take a look at what has been done
in progs/convert/tmhtml. I think that it is a good thing to acquire
more experience first by improving the filter to HTML.
It should also be noticed that some things like htmlout.scm
can be reused for other filters (you even should reuse this
for generating xml).

> I attach a sample tm file and the exported xml generated by my filter as
> examples. As you can see the exporting scheme is very straightforward.

Thanks; I will take a look at this.

> I have not yet tested how well structure of the xml file lends itself to
> xslt transformation.

And that is the big problem... In my opinion we should rather use scheme
to rewrite TeXmacs trees as XML trees and than use "xmlout".