[Scrollkeeper-devel] ScrollKeeper, OMF files, KDE, etc.

[Dan M. <mu...@al...>]

Hi everybody,

Things have been pretty quiet on the ScrollKeeper mailing list lately, so
first let me give a little update: We are approaching our second stable
release, 0.4.0.  New in this release will be support for XML/DocBook docs=
,
index extraction from DocBook/XML docs, better i18n, and a few other
goodies.

In order to implement the features which make ScrollKeeper interesting,
we've added a few ScrollKeeper-specific extensions to the OMF.  It is our
hope that we can get these accepted into the standard OMF metadata.  I
have not been anxious to push this in the past since ScrollKeeper is stil=
l
developing.  Now may be a good time to discuss these issues though.

For a mostly up-to-date description of the differences, see:
http://scrollkeeper.sourceforge.net/documentation/writing_scrollkeeper_om=
f_files/ar01s04.html

In the process of stabilizing the latest development releases, we decided
to require OMF files validate against a DTD.  For this, we have
updated/adapted the standard OMF DTD.  In a couple places, we have added
new attributes (some of which are required).  We have also decided to mak=
e
only the standard 16 OMF elements as XML elements, with all of their
'attributes' as XML attributes.  In contrast, the official OMF DTD has
some things (rights, version, and subject) identified as attributes in
http://www.ibiblio.org/osrt/omf/omf_elements implemented as children.

My first concern is the possibility that I may invalidate existing OMF
files which people intend to work properly with the upcoming stable
ScrollKeeper release.  Does KDE currently install OMF files?  I know GNOM=
E
is rewriting their OMF files for ScrollKeeper 0.4, but I want to make sur=
e
there aren't a lot of KDE OMF files installed which start being rejected
when ScrollKeeper begins validing OMF files.

My second concern is that the OMF as implemented in ScrollKeeper is slowl=
y
diverging from the official OMF.  It would be a good idea to compare the
the OMF spec, the offical OMF DTD, and the ScrollKeeper OMF DTD and decid=
e=20
how we can bring them all into line with each other.  (Or if it is even a=
=20
good thing to have them all be the same?)

My third concern is that we should make sure that we are content with the
OMF implemented by ScrollKeeper.  The backwards-incompatible change we're
making right now probably won't cause any real problems since the install
base is small and since the new GNOME and ScrollKeeper releases will be
fairly synchronous.  In the future it will be much harder to change
things.  So lets try to finalize things soon.  If you have any great
suggestions for changes, lets hear them :)

I'd also like to revive the discussion of merging the OMF into DocBook. =20
This would make things a bit easier on people.  I think we can follow =C9=
ric
Bischoff's suggestion of using a namespace mechanism to include the OMF
metadata in DocBook without conflicts with existing DocBook tags.  Then w=
e
can write an XSLT stylesheet to generate an OMF file from a DocBook doc. =
=20
ScrollKeeper can include this stylesheet along with a short script to run
it, and it can be called at build time to generate the OMF file and
include it in the package.  It sounded like there was a rough concensus o=
n
this approach last spring when it was last discussed, although it would b=
e
good to go over this quickly again.  If people still like the idea, then=20
we should start by trying to finalize the DTD and then ask Norm to work i=
t=20
into DocBook.

Dan