[Doc-SIG] Re: Output writers and XSLT
Thu, 25 Oct 2001 22:35:42 +0100
On Wed, 24 Oct 2001 23:49:14 -0400, David Goodger
>Paul Moore wrote:
>> we can *already* get XML
>> out of reStructuredText. Given that, can we not use XSLT to generate
>> whatever output formats we need?
>Sure can. Remi Bertholet, Paul Wright, and Alan Jaffray already have. =
>the reStructuredText sandbox for their .xsl style sheets.
Interesting... The XSL style sheets don't look over complicated, which
is clearly a good thing. But it is another language to learn.
>> Is that a viable general approach?
>Maybe. Depends what you mean by "viable general".
By "general", I specifically meant can it be used for output formats
other than HTML? By "viable", I was thinking of whether it would be
available to everyone - which comes down to the next point...
>> Does Python include XSLT processing modules? In the PyXML package, =
>In PyXML, yes, I believe so. But not in the standard library yet. Which
>rules it out as a general solution for now. Eventually, I want the
>"docutils" (umbrella package including DPS or a renaming of DPS) to be =
>of the standard library, so it can't use stuff from outside. If PyXML =
>to be included in the stdlib, though...
In other words, packages aimed at the core cannot use technologies which
are not part of the core, even if such technologies are available in
Python, and are appropriate. Grmph. I see your point (although I wish I
OK, so it sounds like XSLT is not a "viable general approach", although
docutils can usefully be a good showcase for its capabilities. ("Look -
we implemented an output processor in only 100 lines of XSLT code").
I'll continue to look at tree-walking solutions.
BTW, in my view, the key output formats which need to be supported are
HTML and at least one TeX derivative (probably either LaTeX or Texinfo).
HTML for web output, and TeX for hardcopy (PDF via PDFTeX, PostScript,
general printed formats via DVI). If and when we have these 2 formats,
we can (IMHO) say we have the output side of things covered. Does this
Paul (posting because it takes less brain power than coding...).