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

[David Allouche]

I will try to summarize what has got out of this discussion at the
moment:

Symbols
-------

Any good XML/HTML conversion tool will need support for TeXmacs
encoding. That include two parts:

  -- conversion of the Cork encoding to iso-8859-1 plus a few unicode
     symbols;

  -- conversion of TeXmacs universal symbols to unicode.

Short of a full unicode support (whatever that means) we may simply
use the standard numerical entity notation.

To this end, we will need a big table which define the relevant
associations between unicode and universal symbols. I think that a
mapping to numerical entity would be appropriate.

Also, I noticed that Felix decided to pass universal symbols verbatim
to XML (and convert < to an universal symbol). In my tm-to-xml tool, I
proposed to represent universal symbols as empty "u" element with an
attribute "s" named after the symbol:

  e.g. &lt;mapsto&gt --> <u s="mapsto"/>

I believe this approach would make it easier to handle conversion
using XSL.

Generally, these tasks will make supporting basic export to XML
trivial, and would make TeXmacs immediately useful to all people who
are working in the angle bracket world. Which is awful lot of people,
including many smart people we would be happy to see contributing to
TeXmacs.

These tasks are not yet official and are not assigned.


Mathematics
-----------

The plans are to support export to MathML visual subset first. That
will allow direct rendering by conformant tools (seemingly not much
beyond Gecko) and processing using commodity filters to produce
documents readable with legacy browsers.

On the longer term, we may support the semantic subset of MathML. That
would require the creation of a mathematical parser to produce an
intermediate "object representation" (where object has the same
meaning as in the tree->object scheme function). That intermediate
presentation would then be converted into MathML.

These tasks are not yet official and are not assigned.


Namespaces
----------

One important point which was missed here, is the difficult part when
using XML is support for namespaces. That make Scheme and XML no
longer equivalent.

Part of the argument about XML may well boild down to "do we support
XML namespaces in scheme". I see that all schemes proposed by Joris do
not. But I do not see myself very well why we would need it but for
one thing:

  importing abitrary XML documents with texmacs using scheme tools
  requires support for namespaces.

Arbitrary XML documents may be DocBook with MathMl and some user
defined tags.

However that is quite a distant prospect so there is no compelling
reason for texmacs to provide more than encoding conversions.


Choice of languages
-------------------

The difficult point is here.

Joris is happy with Scheme and would not like to use another language.

Felix like XSLT and would rather use this than Scheme.

I personnaly like both Scheme and XSLT. They both have advantages and
weaknesses. From a theoretical point of view, Scheme is arguably more
expressive than XSLT. But XSLT is the language tailored to what we
want to do. We may provide facilities in scheme to implement all our
transformation needs using the best imaginable syntax. But XSLT
already provide constructs with solid semantics, so why reinvent?

My solution is to use SXML as a base for interoperation with packages
available on the net:

  http://okmij.org/ftp/Scheme/xml.html

I believed there was already a working SXSLT implementation available,
but it seems I tooks my wishes for reality. Yet there are really
interesting tools there which may make our conversion life easier:

  -- apply-template form in scheme

  -- permissive HTML parser

  -- partial SXPath implementation

My proposition is to try reusing this work. Cooperation with this
other project will probably lead to better tools.

Other usages may be envisioned for sxml. One of them could be
integration with libxslt (from GNOME) to provide a good support for
XSLT. That could make TeXmacs a control tool for XSLT, which is
something I have missed in my past XSLT venture.

My conclusion is at the moment there is no real reason to make a
massive switch to sxml. But partial integration, especially with parts
which are going to evolve much, like the HTML translators, should be
tried since it may make our life simpler and will make contributors
with a love for angle brackets more happy.


More?
-----

If you think I have missed your favorite important point, please let
me know.


-- 
David Allouche         | GNU TeXmacs -- Writing is a pleasure
Free software engineer |    http://www.texmacs.org
   http://ddaa.net     |    http://alqua.com/tmresources
   address@hidden  |    address@hidden
TeXmacs is NOT a LaTeX front-end and is unrelated to emacs.