Mark Johnson <[EMAIL PROTECTED]> writes: > On , January 18, Adam DiCarlo wrote: > > Title: Debian SGML/XML Policy > > DDP Section: Developers' manuals > > Maintainer: Mark Johnson <[EMAIL PROTECTED]> > > Contributors: Adam Di Carlo <[EMAIL PROTECTED]> 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..<[EMAIL PROTECTED]>...<URL:http://www.onshored.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
