Re: Stylesheet parameters and packages?

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.honnen@xxxxxx <
xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

>
> On 07.06.2020 19:40, David Birnbaum djbpitt@xxxxxxxxx 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.