Re: debian xml-sgml policy
Mark Johnson <mrj@debian.org> writes:
> On , January 18, Adam DiCarlo wrote:
> > Title: Debian SGML/XML Policy
> > DDP Section: Developers' manuals
> > Maintainer: Mark Johnson <mrj@debian.org>
> > Contributors: Adam Di Carlo <aph@debian.org> and hopefully others
> > Abstract: Subpolicy for Debian packages providing SGML and XML materials.
> > CVS module name: sgml-xml-policy (?)
> > Format: DocBook XML (?)
> > License: GPL (?)
> >
> > Should I go ahead and create 'sgml-xml-policy' and start adding the
> > Makefiles?
>
> Sure. Get it going. And thanks for doing so.
Do you like the CVS module name I picked? Any other responses to the
'(?)' items?
> We (I, actually) don't have to use debiandoc, do we?
No. DDP-policy has recently been extended to support docbook-xml.
They also have a pretty nice debiandoc -> docbook converter. Haven't
played with it much.
> If not, let's stick to docbook-xml. As I go along I'll think about
> writing a dtd customization layer to subset docbook-xml down to
> something smaller and more fitting to the task. (I actually enjoy
> writing dtd customizations...)
Actually, I think a docbook-xml simplified specifically for debian
documentation would be a good thing. I would suggest you work with
the debian-doc list about this.
For now I would recommend just focussing on the content of the policy
itself. That is a lot of work. You also have a lot of package bugs,
I notice, and a lot of packages that need updates for later upstream
releases.
Of course, it's your time and you can do what you like...:)
> And BTW, Won't the makefiles depend on the dtd, processor and
> stylesheets? I'd prefer to use xsl (rather than dsssl), and would like
> to have the option of using different xslt processors. I don't know if
> any of this is relevant at this point, but I thought I should mention
> it anyway...
We're somewhat constrained by what processors are available on the
machine that builds and updates the documentation.
I would really request that we not worry too much about this yet, but,
yes, look to have flexibility in the processor we're using in the
future.
--
...Adam Di Carlo..<adam@onshore-devel.com>...<URL:http://www.onshored.com/>
Reply to: