Thanks for the quick response, Martin. Working forward from your example, I
found that i had declared the $debug parameter in two low-level files where
one imported the other (which suggests that they weren't both "low-level",
at least in the same way). When I removed the declaration from the higher
of the two, I got the same results that you did. Command-line Saxon EE
10.0J, with -config: and a configuration file instead of specifying the
used packages on with the -lib switch.
On Sun, Jun 7, 2020 at 5:13 PM Martin Honnen
martin(_dot_)honnen(_at_)gmx(_dot_)de <
xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
On 07.06.2020 19:40, David Birnbaum djbpitt(_at_)gmail(_dot_)com wrote:
Is there a rule of thumb for managing stylesheet parameters when using
a package hierarchy, that is, in situations where packages use other
packages? I would like to set a $debug parameter in all packages, both
the lowest-level collections of user-defined functions and the
higher-level packages that import those libraries, and that are then
imported, themselves, by other stylesheets. But as I fiddle with the
options, either I am notified by the mid-level package that a
parameter has not been declared there (even though it is declared in a
lower-level package that I am using in the mid-level one, and the XSLT
3.0 spec tells me that stylesheet parameters are obligatorily public)
or, when I declare the parameter in the mid-level package, that it
conflicts with the lower-level declaration. In case this is helpful,
the point of the $debug parameter is that I want to write diagnostic
messages to stderr using <xsl:message> when the $debug parameter
value is true, and I need to be able to generate messages of this sort
from both the low-level and mid-level packages.
Is that XSLT 3 packages? It might help if you show minimal examples
generating those problems, together with an explanation of the XSLT 3
processor you use.
The simplest samples I could come up with a three packages package1.xsl,
package2.xsl, package3.xsl
<xsl:package
name="http://example.com/mp/p1"
package-version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
exclude-result-prefixes="#all"
version="3.0">
<xsl:param name="debug" as="xs:boolean" select="true()" />
</xsl:package>
<xsl:package
name="http://example.com/mp/p2"
package-version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
exclude-result-prefixes="#all"
version="3.0">
<xsl:use-package name="http://example.com/mp/p1" version="1.0"/>
<xsl:template name="xsl:initial-template" visibility="public">
<xsl:value-of select="$debug"/>
</xsl:template>
</xsl:package>
<?xml version="1.0" encoding="UTF-8"?>
<xsl:package
name="http://example.com/mp/p3"
package-version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
exclude-result-prefixes="#all"
version="3.0">
<xsl:use-package name="http://example.com/mp/p2" version="1.0">
<xsl:accept component="template" names="*" visibility="public"/>
</xsl:use-package>
</xsl:package>
I can run both package2.xsl or package3.xsl with Saxon 10 from the
command line and the value of the parameter declared in package1.xsl is
output. I have to use the option lib:package1.xsl when running
package2.xsl and the option lib:"package1.xsl;package2.xsl" when running
package3.xsl. For simplicity I have also not used an input document but
used the option -it to run that template named xsl:initial-template in
package2.xsl.
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--