Re: Changes to Texinfo DTD

[Nic Ferrier]

Oliver Scholz <address@hidden> writes:

> "Robert J. Chassell" <address@hidden> writes:
> [...]
> 
> > First, it seems to me cleaner to write an XML renderer that can
> > standalone, and then write separate code to enable the standalone Info
> > to choose whether to use its current renderer or the new one.
> 
> I take that to mean: to write an entirely new program that does the
> same job as the current standalone reader, but renders XML. I fail to
> see the benefit. I admit that it would be conceptually nicer to have
> the program keep the XML document as a DOM-like tree of nodes in
> memory rather than as a flat string of characters (for the internal
> representation would be the only difference to my proposal). But I do
> not see what difference it would make for a user. But maybe I am
> missing something.
> 
> More importantly: it would be a *lot* of work and you would need
> somebody who implements it.  I am certainly not going to write an
> entirely new standalone XML browser in C.  But I am willing to
> implement my proposal and I am willing to do it now.

It wouldn't be a lot of work. It would be trivial with XSLT. There
are basically 2 ways of doing it:


Method 1.
a) patch makeinfo so the XML output can be chunked.

b) prepend an xml-stylesheet processing-instruction to each chunked
   file

c) write an XSLT stylesheet to turn the XML into HTML with navigation
   written in Javascript (so key bindings can be used)

d) serve the files to Mozilla (or IE or any other XSLT aware browser)
   and it will render the XML using the stylesheet

e) For Emacs/W3 we'd have to write an XSLT processing solution, they
   are being worked on I understand. It would be very trivial to write
   one using a command line XSLT tool but see method 2.


Method 2.

a) use a command line XSLT tool such as xsltproc (from the GNOME
   libxml2 project: http://www.xmlsoft.org) to chunk AND style to HTML
   the output of makeinfo --xml.  
   The styling would be as method 1, part c.

b) serve the files, they would be HTML so Emacs/W3 would be able to
   read them without alteration.




> > Second, you could write code to enable GNU Emacs to run a standalone
> > XML renderer, the way it now runs W3M mode -- the advantage of this is
> > that more people would test the standalone XML renderer than they
> > would if it only worked outside of Emacs.
> [...]
> 
> That would also be a *lot* more work and maybe it could even be worse
> performance-wise than rendering the XML directly in Elisp. You'd have
> the process communication *and* you would still need to parse and
> render some ad hoc made markup from the standalone reader.

Nah. Just call out to a command line XSLT engine to turn the XML into
HTML.

This project needs doing anyway because most browsers do it. I'd be
happy to undertake this work on Emacs/W3.



Nic