Re: where is sdocbook-xml
Mark Johnson <mark@phy.duke.edu> writes:
> Adam Di Carlo writes:
> > I would suggest you get the packages uploaded even based on your
> > suggested structure, and then we can change it later.
> Should I do that, or just put in the /usr/lib/sgml parts? Lemme know
> and I'll get them ready.
> (By "full setup" at the bottom I meant both /usr/lib/sgml/ and
> /usr/share/sgml/.)
I dunno -- maybe you should retain /usr/lib/sgml for now until docbook
and docbook-xml changes (since much your stuff depends on them) ?
Seems easiest until it all stabilizes...
> > Why wouldn't it just provide 'xsl-processor'. Likewise, jade/openjade
> > should provide 'dsssl-processor'. Isn't this what you're asking for?
>
> No, that won't do it. Only a subset of the xslt processors will work
> with the docbook xsl stylesheets. We need some easy way for users to
> install packages that'll work for _docbook_ xsl processing.
>
> The reasons are that some xslt processors have less than complete XSLT
> implementations, and that Norm (sometimes) uses special extensions
> only supported by a subset of the xslt processors. The situation
> doesn't allow for generic specification of processors, though someday
> that'll likely be the case.
Then just specify that if the XSL processor is not good enough to
process this or that document with this or that stylesheet, it cannot
claim to be an xsl-processor?
Anyhow, you are just requiring a certain level of XSLT or XSLFO
compliance. An alternative is to construct virtual package names
based on what standards the processors comply with:
xlst-1.0
xlst-1.1
xls-1.0 # XSL FO
My understanding is that the lack of tool stability in the XSL
toolchain is something that is temporary and will change, say, by 2-3
years from now. You have to think long-term in Debian. Problems Norm
is having now may be an immediate symptom, but we shoudl fix the
problem right so we don't have to do a painful transition later.
> Also, catalog support is only available for a few processors
> (currently xt and saxon), though that may change when Norm releases
> his new catalog classes.
Well, the question is whether that makes or breaks support for
different processors. My undersatnding is that even if there is no
catalog support, there is always ways of invoking the tools to work
(you just have to get the filesystem locations right).
> They're java packages, distributed as compiled classes. I was trying
> to ask whether the classes need to be recompiled before they get
> packaged.
Hmm. You'd have to take that up with debian-java, I don't know.
> I'll hold off on the /usr/share/sgml/ parts though, so the postinst
> doesn't choke on the update-catalog part. Does that sound OK?
Yup.
--
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
Reply to: