texmacs-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Felix Breuer
Subject: [Texmacs-dev] HTML, XML, XSLT (was: texmacs installation problem)
Date: 16 Nov 2002 12:23:32 +0100

Hello Joris and David! 

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. 

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". 

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. 

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?

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.

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

So direct HTML export may yet be the better option.

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. I
have not yet tested how well structure of the xml file lends itself to
xslt transformation.

Regards,
Felix

Attachment: test.tm
Description: custom/7bb43382-f5eb-4d1b-b34b-b34f9d9ab6c7

Attachment: test.xml
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]