Re: [Scrollkeeper-devel] Relations with OMF

[Eric B. <e.b...@no...>]

Le Friday 27 April 2001 10:46, Dan Mueth a =E9crit :
> On Fri, 27 Apr 2001, Eric Bischoff wrote:
> > Speaking about this, one of the concerns at KDE was "how do we extrac=
t
> > OMF data out of our docbook files?". We did not wish to store the OMF
> > meta-information in a separate file. So the idea so far is:
> > - to automatically extract DocBook meta-information which has OMF
> > equivalent - to store OMF meta-information which has no DocBook
> > equivalent (like the position in the categories tree) in the DocBook
> > file, using XML namespace to differentiate it from plain DocBook, the=
n to
> > extract this information as well.
>
> In the long term, I think we want to have the OMF elements added to
> DocBook.  (You may recall that Norman Walsh thought this was a good ide=
a
> at the O'Reilly Summit.)=20

Sure, but ScrollKeeper is becoming a reality now, so we need at least a=20
transitory solution. Furthermore, some people might not be able to switch=
=20
immediately to latest DocBook version when OMF tags will be available, if=
=20
ever.

> This way authors would only maintain one
> file.  For the sake of maintaining databases and such, we may still
> generate OMF files, but that is not of significance to the document
> authors.

Sure. But if we use OMF tags with namespace, transition to=20
DocBook-with-OMF-tags will probably be easy when it will be available.

> Before we can do this right, we have to stablize ScrollKeeper and the O=
MF
> DTD to some extent.  Then we need to have the new tags added to
> DocBook.   This takes a while, so I was planning on just using seperate
> OMF files in the interim.

The problem with external files is that it adds a risk of unsynchronizati=
on=20
with main file, needs you to open twice in your editor, needs the transla=
tors=20
to copy the external file, etc... Nothing very serious, but still adding=20
complexity while doc writers and translators are busy enough already. If =
we=20
can spare them this effort, I feel it will be welcome.

> Your suggestion of adding tags which have their own namespace inside of=
 a
> DocBook document is interesting.  If we did this, would the document st=
ill
> be a valid DocBook document which can be parsed by any standard DocBook
> tool?

... and if yes, will the OMF tags be validated inside of their own DTD?

We are exactly investigating those topics right now at KDE. I'll keep you=
=20
informed of the results. For the moment I'm very ignorant about namespace=
=20
issues.

Maybe Norm knows more than us about this, after all he already investigat=
ed=20
issues like DocBook + MathML inclusions.

> My impression was that it would not, but you know much more about
> this than I do.  Or perhaps I am misundestanding what you mean.

No, you understood perfectly. My opinion is that it will work, but only a=
=20
real-life test will be able to tell us the truth ;-). Also, if it does no=
t=20
work, nothing prevents us from preprocessing the "merged" file to separat=
e=20
the DocBook on one side from the OMF on the other side ;-).

--=20
+----------------------------------------------------------------------+
| =C9ric Bischoff                              mailto:e.b...@no... =
|
+----------------------------------------------------------------------+