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

[Frederik F. <fo...@Co...>]

[...]

| I'd also like to revive the discussion of merging the OMF into DocBook.  
| This would make things a bit easier on people.  I think we can follow Éric
| Bischoff's suggestion of using a namespace mechanism to include the OMF
| metadata in DocBook without conflicts with existing DocBook tags.  Then we
| can write an XSLT stylesheet to generate an OMF file from a DocBook doc.  
| 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 on
| this approach last spring when it was last discussed, although it would be
| good to go over this quickly again.  If people still like the idea, then 
| we should start by trying to finalize the DTD and then ask Norm to work it 
| into DocBook.

If I'm right, a subset of the Dublin Core will be in the next
DocBook DTD release (4.2), which is quite close: they have
Release Candidate 1 currently.  (The OMF extends on the Dublin
Core Meta Data.)  There is a mapping from Dublin Core elements to
DocBook elements available.  (See the DocBook web pages.)

I find it a bit worrying that there are now so many different
subset relations (DocBook meta data < Dublin Core Meta Data < OMF
<?  Scrollkeeper; < means here "subset of"), but subsets are
still better than only intersecting sets.  Extension are not
_really_ a problem, as long as they are _only_ extensions, or as
long as there is an unambiguous mapping from one into the other.
These mappings need to be defined "officially" - anything else
will lead to divergences in interpretation.

Greetings,

Frederik Fouvry
KDE DocBook