Adding Docbook 4.3 and DocBook XSL 1.65.1 to kdelibs

[Frans Englich]

On Monday 16 August 2004 07:27, Lauri Watts wrote:
> On Monday 16 August 2004 04.22, Frans Englich wrote:
> > Hello all,
> >
> > I'm working on two documentation projects on usability.kde.org, KDE
> > Usability Articles, and a face lift of the Human Interface Guidelines.
> > Both use docbook, and the docbook DTDs as well as XSLs must be available
> > in order for people to work with those two projects.
> >
> > Specifically, the two need:
> >
> > * Docbook XML 4.3
>
> This is just not very likely to happen.  It's an enormous amount of work to
> update, while keeping backwards compatibility,  and supporting the older
> versions, and keeping it working across dozens of languages.

We don't have to upgrade, we have already two Docbook XML DTDs in 
kdelibs/kdoctools/docbook, and we can add another; the choice of using v4.3, 
which will happen sooner or later anyway. It wouldn't touch the current 
system, and no more work than the initial commit(I'm not talking about 
upgrading in the sense of replacing, in other words).

>
> There's nothing at all stopping you using your own copy of either of these,
> meinproc has a --stylesheet option, as do any other xslt processor I ever
> saw.
>
> > * Docbook XSL 1.65.1: Formatting Objects and XHTML output
>
> This is even less likely.  Updating the XHTML to 1.65.1 is possible
> (*after* this release is out),

HEAD is open for feature commits(3.4/4.0), or I've gotten it wrong?

> but there's no use to KDE to have the FO 
> stylesheets there.  KDE doesn't use them, and is unlikely to any time soon
> (which is why the current version imported in kdelibs doesn't have them.)
>
> > Docbook XML 4.3 is on <500kb, so I guess it's ok if I add it to kdelibs.
>
> Please just don't touch kdelibs/kdoctools/docbook.   You can quite easily
> break all of KDE *and* all third party apps from building, and I don't
> expect you're offering to do all the work required to support this.

Correct, certainly not, because that would be irrelevant. As said above, I'm 
not into replacing, but suggesting what is done before: Adding newer versions 
in parallel, isolated from the current. No fiddling with current code.

>
> > DocBook XSL have grewn significantly in size however, even if it's
> > stripped similarly to the kdelibs/kdoctools/customization/xsl, the size
> > is 7.9mb, compared to the current on 2.9mb.
> >
> > The above functionality is widely used, and should be available centrally
> > in KDE. The size is daunting but it have to be consumed somewhere, the
> > question is where.
> >
> > If it should be placed in kdelibs(if not, it will probably lead to
> > duplicates in the long run), should it replace
> > kdelibs/kdoctools/customization/xsl or be another version, similar to the
> > DTDs? I don't have insight in the KDE doc system to spot regressions etc.
>
> It's a massive job, and not at all urgent, as far as I can see.

While it is clear adding the above is not a massive job since we're talking 
about two imports and is in addition done by me, it can of course be 
questioned whether it is important: I obviously need XSL-FO and recent 
versions for the two projects, and then it's matter of whether the HIG is 
important and part of KDE. As you write: "There's no use to KDE to have the 
FO stylesheets there.  KDE doesn't use them."

I think this question boils down to why Docbook is in kdelibs at all: It's not 
installed, and is only a dependency for developers -- a scope my uses lives 
up to. The logic is simple: when documentation development justifies its 
existence, usability development should too.

Docbook is in kdelibs because it is a pain to locate on the setup and getting 
to work(or correct me). And guess what is one of the reasons to why I want to 
use a copy in kdelibs. Since we've chosen to cache docbook, it makes sense to 
upgrade it when demands on up-to-date versions emerges.

What if it not gets accepted? Assuming I have permission, I will commit in 
another module, for the same reasons docbook is in kdelibs now. But I can't 
see how I will have, judging from the current arguments. Another day, someone 
will post a similar message to mine, and off we go.

Stephan, regarding size: I've stripped 1.65.1 similarly to kdelibs' 1.48, but 
obviously kept fo and xhtml. The latter was released two years ago, I guess 
that justifies developing tentacles. No, I don't like the size either :| If 
it was possible to literally upgrade the XSL sheets, we would save 3mb. The 
KDE customization's backwards dependency amazes me, but that's hardly 
surprising considering my shallow insights.

>
> Anyway, the right list is kde-docbook (or kde-doc-english), this is hardly
> core-devel territory.

Ok. Moving discussion.


			Frans