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

[David Allouche]

Wow, I am glad that my comments about XML and HTML sparked such a
discussion.

On Fri, Nov 15, 2002 at 03:56:06PM +0100, Joris van der Hoeven wrote:
> 
> > > I think that improving the Html output filter in such a way that
> > > it is good enough for converting our webpages is a matter of a few days.
> > > So this can be done shortly after the release of version 1.0.1.
> > 
> > I am quite unsure about that. Esp., considering that I would probably
> > use that occasion to introduce commodity SXML code into TeXmacs.
> 
> Yes, but if one always wants more and more, then one does nothing.
> We sometimes have to accept loosing a bit of time in order to
> implement something which does not have a full generality.
> Implementing a good Html filter falls into this category:
> having a complete set of XML/SGML tools might inded make it
> much easier to implement such a filter. But writing these tools
> would require a lot of time and thought.

It looks like you misunderstood me. When I say "introduce commodity
SXML code" I actually mean "copy GPLed SXML code from the web into
TeXmacs". This will not require this much time and though. Just
ironing out portability issues to GUILE, if that has not already been
done.

I am unsure that improving your HTML filter will only take a few days
simply because I did not look at it yet. And introducing existing SXML
code and updating the existing conversion tools to use will probably
take a few days by itself.


> > I had a look at it. It is quite easy to offer a half-assed SXML
> > implementation (that is what I am hacking with), but the full thing is
> > really non-trivial.
> 
> Yes and because it is non trivial, it is good to obtain
> some experience first by implementing an Html filter.

I meant, because it is non trivial, it is good to reuse code other
people are already using. That will give us more with less work.

 
> > I believe I have a bit of experience know in
> > document conversion (thought I have not studied your html conversion
> > code yet), and I tend to think we should be using SXSLT for most of
> > the logic.
> 
> Since you do not have the experience... same conclusion.

I do have some experience with XSLT:

    http://ddaa.net/old-site/daweb/doc/daweb.html

And now I have some experience with performing tree conversions in
Scheme. I gather from that experience that XSLT provides semantics
which allow for readable and expressive (read, short in number of
individual semantic constructs) tree transformations. However I agree
that Scheme is more general, and for specifics things we may need to
interact closely with TeXmac's core. Finally I do not want to
mulitiply languages used in TeXmacs development.

That is why I currently think the right solution is to use SXSLT. I
have to make sure that we can mix SXSLT code and 'usual' guile code,
but this granted I really think that will give use the best possible
tool, and for little work.


> > Generally, the editor give a lot of freedom to the user in producing
> > documents with improper (or simply surprising) structure. That makes
> > creating robust conversion filters non-trivial. Even for regular
> > documents, the document/concat based structures are generally not
> > trivial to handle, esp. since in many case the document may contain
> > improper block/inline/block structure nesting without it causing
> > obvious problems to the user.
> 
> Yes, and you will not solve this problem in a few days.

I do not mean to solve it all right now. I just mentioned a problem
which annayed me at the moment.

I believe we can use partial solution very quickly since that would
only involve changing some things in the keymap and introduce some
hooks to scheme code in the editor. I will develop more on that later.
I will make my changelog tools public and they do include some
interesting (IMHO) keymap work.


> > I am thinking to make the editor more restrictive in producing such
> > incorrect structures. That is not going to be easy for copy-paste
> > operations, but for normal input operations I believe that would not
> > be difficult. You could get some inspiration on that matter by using
> > Amaya.
> 
> I already know what should be done here and I explained part of that
> before on this mailing list. However, it will require a month or so
> to implement that.

Great then. It is just too bad no one has referenced those previous
mails and there is not search engine for the archives at mail.gnu.org.


> > Then maybe you could write it out (with afferent comments) on the task
> > manager...
> > 
> > It has a nice "task depends on task" feature. Kind of what allows you
> > to produce those nice GANTT charts managers are so fond of ;-)
> 
> Do we have that on Savannah?

Actually, not the chart generation, yet :-). I said "kind of what
allows you", not "which allows you".

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