OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: DOCBOOK-APPS: Re: srcdir/objdir issues and including variableusability issues with xsltproc


>>>>> "JL" == John Levon <levon@movementarian.org> writes:

[...]

JL> I'm aware of catalogs. They aren't a solution because users have
JL> to modify their boxes.

Not necessarily (see below).

>> By default xsltproc will look for catalogs in /etc/xml/catalog, so
JL>                                              ^^^^^^^^^^^^^^^^

>> you set that up to point to right place(s) for the installed
>> DocBook files, your users won't need to modify their environment at all.
JL>          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


JL> This is a direct contradiction. The XML tools are hard enough to
JL> install, I do not want to request some extra configuration.

I was initially thinking that you were referring to a multiuser system
whereby the installation of the RPMs were being done globally by the
system administrator, and the users were on the same system, in that
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
using a combination of basic Makefiles (no autoconf necessary) and
catalogs.

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.

If it is Red Hat, the XML tools are normally included as part of a
default distribution.  If you already have the stylesheets installed
as part, then the /etc/xml/catalog file should already have added the
entry to the stylesheets to this global catalog in the post-install
script in the RPM.

JL> I have wished for a long time that all the Linux distributions
JL> would add their xsl-stylesheets installation path as a catalog
JL> entry, but this hasn't (to my knowledge) happened. 

But they do.  Here's my /etc/xml/catalog on Red Hat 8.0 (I did not
have to modify it all):

<?xml version="1.0"?>
<!DOCTYPE catalog PUBLIC "-//OASIS//DTD Entity Resolution XML Catalog
V1.0//EN"
"http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd">
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">

[...]

  <rewriteSystem
systemIdStartString="http://docbook.sourceforge.net/release/xsl/current" rewritePrefix="file:///usr/share/sgml/docbook/xsl-stylesheets-1.58.1-1"/>
  <rewriteURI
uriStartString="http://docbook.sourceforge.net/release/xsl/current" rewritePrefix="file:///usr/share/sgml/docbook/xsl-stylesheets-1.58.1-1"/>
  <rewriteSystem
systemIdStartString="http://scrollkeeper.sourceforge.net/dtds/scrollkeeper-omf-1.0/scrollkeeper-omf.dtd" rewritePrefix="/usr/share/xml/scrollkeeper/dtds/scrollkeeper-omf.dtd"/>
  <rewriteSystem
systemIdStartString="http://docbook.sourceforge.net/release/xsl/1.58.1" rewritePrefix="file:///usr/share/sgml/docbook/xsl-stylesheets-1.58.1-1"/>
  <rewriteURI
uriStartString="http://docbook.sourceforge.net/release/xsl/1.58.1" rewritePrefix="file:///usr/share/sgml/docbook/xsl-stylesheets-1.58.1-1"/>
</catalog>

The post-install script for DocBook XSL uses the xmlcatalog (part of
libxml) program to add them:

[alex@delpy alex]$ rpm -q docbook-style-xsl --scripts
postinstall scriptlet (through /bin/sh):
CATALOG=/etc/xml/catalog
/usr/bin/xmlcatalog --noout --add "rewriteSystem" \
 "http://docbook.sourceforge.net/release/xsl/1.58.1" \
 "file:///usr/share/sgml/docbook/xsl-stylesheets-1.58.1-1" $CATALOG
/usr/bin/xmlcatalog --noout --add "rewriteURI" \
 "http://docbook.sourceforge.net/release/xsl/1.58.1" \
 "file:///usr/share/sgml/docbook/xsl-stylesheets-1.58.1-1" $CATALOG
/usr/bin/xmlcatalog --noout --add "rewriteSystem" \
 "http://docbook.sourceforge.net/release/xsl/current" \
 "file:///usr/share/sgml/docbook/xsl-stylesheets-1.58.1-1" $CATALOG
/usr/bin/xmlcatalog --noout --add "rewriteURI" \
 "http://docbook.sourceforge.net/release/xsl/current" \
 "file:///usr/share/sgml/docbook/xsl-stylesheets-1.58.1-1" $CATALOG
postuninstall scriptlet (through /bin/sh):
CATALOG=/etc/xml/catalog
/usr/bin/xmlcatalog --noout --del \
 "file:///usr/share/sgml/docbook/xsl-stylesheets-1.58.1-1" $CATALOG

JL> Additionally, xsltproc does not have an option for adding a
JL> temporary catalog entry that I could see.

You can set your XML_CATALOG_FILES to a new catalog, which includes
the system one (using <nextCatalog/>), or I believe that xsltproc now
supports colon-delimted files, so that:

XML_CATALOG_FILES=catalog:/etc/xml/catalog

should work.

JL> Of course, this does not solve the problem of finding the .xsl
JL> files I need on top of the DocBook ones, or the other problems I
JL> mentioned.

To elaborate a little on Jirka's solution, if you already have the
value of $srcdir in a variable in your Makefile you could encapsulate
all of this by creating a a temporary target catalog, and then
pointing XML_CATALOG_FILES to that target (untested):

catalog:
   echo "<catalog xmlns=\"urn:oasis:names:tc:entity:xmlns:xml:catalog\" prefer=\"public\">" > catalog
   echo "<nextCatalog catalog=\"file:///etc/xml/catalog\"/>" >> catalog
   echo "<uri name=\"foo.xsl\" uri=\"$srcdir/foo.xsl"\/>" >> catalog
   echo "</catalog>" >> catalog
## or, more succintly, you could use xmlcatalog (as shown above)

all: catalog
   XML_CATALOG_FILES=catalog xsltproc foo.xsl bar.xml > frob.txt

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,

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).  I think that variable
expansion is specifically not allowed because all "href"s in
xsl:{include,import} need to be valid URIs according to the XSLT 1.0
spec.

Whether this limitation makes sense or not is another question, but I
think the reasoning is that resolution of URIs should left to the
catalog system and is otherwise outside the scope of XSLT, i.e. what
would be a sensible default if your $srcdir in your example:

<xsl:param name="srcdir"/>
<xi:include href="$srcdir/xsl/xhtml-non.xsl" xmlns:xi="http://www.w3.org/2001/XInclude" />

was left blank (i.e. not set)?  Should the URI be "/xsl/xhtml-non.xsl"
or "/home/user/xsl/xhtml-non.xsl".  I'm guessing that they simplified
the spec by requiring that all href's be valid URIs, and let the
catalog system do the resolving (and in turn the catalogs can be
generated and/or manipulated by the build system, which is outside the
scope of the XSLT spec).

I'm not sure whether this issue has been addressed in XSLT 2.0 or
not.  

Alex




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]