OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [docbook] SGML support



How good that you replied.

On Tuesday 21 December 2004 21:18, Shaun McCance wrote:
> On Tue, 2004-12-21 at 14:55, Frans Englich wrote:
> > On Monday 20 December 2004 21:58, Norman Walsh wrote:
> > > At the DocBook TC meeting this month, I took an action to point out
> > > that our current plans for DocBook V5.0 will probably have less
> > > support for SGML than the current DocBook V4.x line.
> > >
> > > Our plan of record is to work with a RELAX NG schema from which we
> > > will generate a W3C XML Schema and an XML DTD. The DTD is not likely
> > > to have much in the way of parameterization. It's going to be a
> > > "compiled" product much more than a "source" product. This is a
> > > consequence of the fact that we're taking advantage of some of the
> > > expressive power of RELAX NG. The DTD will be significantly "looser"
> > > than the schema.
> > >
> > > The current 4.X line only supports SGML in a few small ways: it
> > > supports some forms of tag minimization and a few inclusions and
> > > exclusions. It's not clear to me that there's value in trying to
> > > preserve this support in the V5.0 line.
> > >
> > > The TC would very much like the community's feedback on these plans.
> >
> > KDE, one of the desktop environments, uses Docbook heavily for all
> > application documentation(help browsers and so forth). The current system
> > have been there for long and leans towards SGML.
> >
> > While I don't speak for KDE, I personally see clear obstacles because of
> > not using XML, and there is a pressure towards XML. KDE is soon to start
> > a new major version(binary compatibility is broken and other large
> > changes), and if Docbook 5.0 arrived in a suitable timeframe, KDE would
> > probably start the major work of switching, I estimate.
> >
> > >From my perspective, I do not at all mind dropped SGML support, and
> > > welcome
> >
> > the new Docbook version. Also, it wouldn't hurt if it didn't take too
> > long to arrive.
>
> Frans:
>
> I'm curious which SGML features KDE is using, and what processing tools
> you're using for your DocBook.  We dropped SGML support in Gnome about a
> year ago, so this is potentially a serious interchange issue, especially
> if we ever standardize on a single help system.

As Lauri explains I was in wide terms wrong about SGML, the concrete I found 
was an SGML catalog(but that can be corrected again).

Regarding processing tools is "meinproc" used; a c++ program which wraps 
xmllint. It duplicates some command line args, and otherwise carries various 
paths specific to KDE. One reason to the existence of meinproc is that the 
docbook files installed uses customized docbook, public id  "-//KDE//DTD 
DocBook XML V4.2-Based Variant V1.1//EN", combined with custom entities, and 
a system id which doesn't resolve; e.g. the docs aren't standalone but 
requires infiltration of the KDE setup.

The topic of document integration between GNOME, KDE, and other projects, is 
very interesting, and a task which would require coordination. What is a more 
suitable moment than when the two large desktop environments thinks of major 
upgrades, and the next generation of Docbook is around the corner? It would 
be a pity if both of them went through the hazzle of turning everything up 
side down, to then do it again later, this time in the name of integration.

Eric Raymond, while thrilled by Docbook's possiblities, wrote "DocBook 
Demystification"[1], where among practical details he pondered on the 
possibilities of the open source system with integrated, unified, powerful 
documentation. For example:

"DocBook might help get us to a world in which all the documentation on your 
open-source operating system is one rich, searchable, cross-indexed and 
hyperlinked database (rather than being scattered across several different 
formats in multiple locations as it is now)."

Perhaps we can move in that direction. More concrete, it would mean a 
collaboration between the relevant people, at the Free Desktop[2] platform, 
hopefully leading to a specification which solve those various technical 
issues.

What that paper would specifically contain I don't really know currently :) 
but doing that evaluation and starting the brain storming would probably be 
the most strategically to do before any of gnome or KDE do a major upgrade.

I have a lot of projects on my TODO, but I will try to look at it during KDE 4 
development.

Shaun, feel free to subscribe to kde-docbook if you want to peak into KDE in 
this matter. Not that it happens much on the list :) it's very low traffic, 
but it will be CC'd in case anything happens:

https://mail.kde.org/mailman/listinfo/kde-docbook


Cheers,

		Frans


1.
http://en.tldp.org/HOWTO/DocBook-Demystification-HOWTO/



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]