[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]