Adding Docbook 4.3 and DocBook XSL 1.65.1 to kdelibs

[Lauri Watts]

On Monday 16 August 2004 11.14, Frans Englich wrote:

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

We have two DTD's because those are the two in use by KDE.  The only reason to 
add another, is if it's in use by KDE.

Either we upgrade the KDE DTD's, or the import is pointless bloat and won't be 
happening.

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

The KDE is not built with or distributed with KDE.  If you want to use the FO 
stylesheets, use them, they are not useful to 

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

It's a dependency for building, and not all people building are developers.  
It allows us to depend on a specific known to be working configuration 
without having to support the hell that was jade, and without having to deal 
with multiple docbook versions as might be supplied by the distribution.  
We've been down that road, and it was extremely difficult and time consuming.

However, the websites (all of them, including usability) are not part of the 
KDE build process.   There's a reason they are in separate CVS modules.

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

Only if there are specific features in the new version that we want to use.    
I haven't seen any request for any of these features yet by any KDE 
documentation writer.

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

Commit it in your usability website module then.  Don't bloat kdelibs for 
*every user* to support one website.

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

The backwards dependency for the DTD is vital for third party apps, since 
there's a lot of them out there who simply don't update the DTD in their 
docs.   It's not going away, and is a hard requirement, just like binary 
compatibility for libs are.  In fact, it's pretty much the same thing.  

I already said that I would upgrade the stylesheets, but it will require some 
reworking of the KDE customizations, and it won't be happening this week.   A 
bare import *will* break the KDE doc rendering, I know, because I've tested 
it.

I still see absolutely no reason to include the FO stylesheets at this point.

Regards,
-- 
Lauri Watts
KDE Documentation: http://docs.kde.org
KDE on FreeBSD: http://freebsd.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20040816/1d7fe9b9/attachment.sig>