This is the mail archive of the
docbook-apps@lists.oasis-open.org
mailing list .
Re: Re: srcdir/objdir issues and including variableusability issues with xsltproc
On Sat, Mar 08, 2003 at 04:20:20AM -0800, Alex Lancaster wrote:
> case it's not a direct contradiction. If you are talking about the
> users installing the basic tools on the system as well, then clearly
> extra configuration is necessary, but you can hide it from the user
No, I am talking about my distributed tarball being buildable on another
system that I have no control over.
> You don't specify what system you have. Since you're using rpm, I'm
> would assume probably Red Hat or a RPM-based distro.
This is pretty much irrelevant - not everybody has Red Hat.
> But they do. Here's my /etc/xml/catalog on Red Hat 8.0 (I did not
> have to modify it all):
> systemIdStartString="http://docbook.sourceforge.net/release/xsl/current" rewritePrefix="file:///usr/share/sgml/docbook/xsl-stylesheets-1.58.1-1"/>
You say you didn't modify it, yet you have a more recent version of
xsl-stylesheets than Red Hat distribute ? Anyway, although I have these
entries :
<phe> /etc/xml doesn't exist
This would indicate there is some way to go before this can be relied on
(and yes, he does have the stuff installed and working).
> XML_CATALOG_FILES=catalog:/etc/xml/catalog
I can't rely on the location or existence of such a file. I hope that
won't break xsltproc - I'll try your solution.
OK I've just tried it again with :
XML_CATALOG_FILES=xsl/catalog.xml:/etc/xml/catalog xsltproc -o \
oprofile.html --stringparam version 0.6cvs ./xsl/xhtml.xsl \
../doc/oprofile.xml
Same error.
> I agree with your point that it would be nice if XSL would allow
> variable substitution (as it does for other <xsl:param/>s) in
> <xsl:import/> and <xsl:include/>, but it's a limitation of the XSLT
> 1.0 spec, not a limitation of xsltproc itself,
Sure.
> I've run into the same problem as you, and initially I was frustrated,
> but with XML catalogs and a little make and shell it's possible to do
> most of what you want without too much fuss (if you encapsulate in way
> that hides the details from the user).
Compare and contrast with gcc -I. It's crazy. I'm quite sure catalogs
admit of some very clever things, but it seems they forgot about the
basic things.
regards,
john