Re: [Cp-tools-discuss] DebugDoclet >> XmlDoclet

[Alex Lancaster]

>>>>> "NF" == Nic Ferrier <address@hidden> writes:

[...]

>> Good point. I'm currently using Apaches' Xalan for XSLT processing,
>> that's not completely GNU but its preferrable to Sun software isn't
>> it?

NF> It's not at all GNU and no, it isn't really acceptable because of
NF> the licence issues.
  
>> On one hand we should keep our work free of dependencies on
>> non-free software. On the other, sticking to 'old' stuff instead of
>> using current technology may be a bad decision as well.
>> 
>> In every case, I assume there are GPLed XSLT processors (or there
>> will be in near future) so I don't think this is really a problem.

NF> Please don't assume that. Unless someone writes one we won't have
NF> one and we will be in the embarrassing position of relying on
NF> Apache code.

NF> The nearest we get to having an XSLT processor is the Saxon tool
NF> and that is MPLed (which does link to the GPL).

NF> My personal view is that, if you need an XSLT engine, you should
NF> use Saxon.

What about libxslt (xsltproc is the command processor) name from
Daniel Veillard (http://xmlsoft.org)?  It's basically now the default
GNOME XML / XSLT library.  It's now under the MIT license (it was
formerly dually licensed under the LGPL and W3 license).  It's a fast
C-based engine and I've been really impressed by it's W3 standards
compliance.  It's not officially GNU (but it is under the GNOME
umbrella, which means that it's close), but I don't think that there
is an official GNU XSLT project, libxslt comes the closest (and will
probably be the most ubiquitous, at least for GNU/Linux systems).  All
the GNOME docs use DocBook and will use libxslt to turn that into HTML
and PS.

We shouldn't not provide XML capability because of that restriction.
It simply can be an extra option.  It's also straightforward to have
the doclet generate XML output and provide an XSL stylesheet that can
used (or not used), so that it can be generated without depending on
the existence of an XSLT processor at all, i.e. we wouldn't be
"relying" on any XSLT processor.

>> My XSLT code currently relies on Xalan because it needs some
>> special functionality for writing output to several files but this
>> dependency is very local and can be replaced easily.

NF> Please don't do this. It's completly against the principles of the
NF> GNU project.

Yes, we should keep as much as possible to XSLT 1.0.  However, if it's
the <xsl:document> function which you're referring to it's actually a
common extension to many XSLT processors (and is in XSLT 1.1 I
believe).

>> > - don't bother with frames.  > - keep to HTML 2.0
>> 
>> I see your point, but I think when we have a fully-featured doclet
>> that uses frames and HTML4+CSS+whatever, it's not a big deal to
>> downgrade this. To be exact, I _know_ that it's no problem to
>> downgrade the XSLT sheet so that it delivers to any minimal
>> browser.

NF> Ok. I can see the point of writing something that produces very
NF> flexible HTML.

Exactly, you can layer on different stylesheets to get any desired
XML/HTML output (including plaintext).  One stylesheet I'd probably
try and write soon would be one that generated DocBook XML.

NF> But bear in mind that the important point is to fit in with the
NF> GNU project as a whole, there is real value in that.

I think it could be argued that GNOME is part of the GNU project and
that libxml/libxslt is part of GNOME, so we could have that covered.

In any case, if we keep the toolchain for the current texinfo output
separate from the XML output (i.e. it wouldn't depend on the existence
of any XML/XSLT parser) then we are fitting in with the GNU project
because we are delivering docs in texinfo which is the GNU standard,
and anything extra is simply icing on the cake!  So texinfo would be
the "default" doclet in this scenario.

Alex