Re: import, include, and packages?

Thank you, Michael!

On Thu, Apr 23, 2020 at 1:00 PM Michael Kay mike@xxxxxxxxxxxx <
xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

>
> 1. I think the advantage of using <xsl:package> over <xsl:import> and
> <xsl:include> for my case (importing a single function [but see below about
> arity]], from a package that does not import anything itself) is that I can
> expose only the function that I want to expose, and not any other named
> components of the imported package (variables, helper functions, etc.). If
> that understanding is correct, it does sound like an advantage. (I want to
> be able to run the code in Saxon HE, so being able to precompile the
> package, which would be a benefit under other circumstances, would not be
> relevant in this case.)
>
>
> Certainly, being able to restrict what you expose is one of the benefits
> of using packages. Also, you have much more control over what can be
> overridden, and how; it's the fact that overrides must be type-compatible
> that enables packages to be separately compiled.
>
>
> 2. I don't understand how (or whether it is possible) to import packages
> without setting up a configuration file. If it isn't, that would seem to be
> a disadvantage for my use case, since anyone else who wanted to use my
> function library would have to set up a configuration, as well., and not
> just get a copy of the package file itself If I have understood correctly,
> the spec seems to say that the configuration is implementation-dependent,
> so if one is needed, where would I find documentation about how to set it
> up for use by Saxon, both at the command line and inside <oXygen/>? If a
> configuration setup is not requiredbthat is, if it is possible to specify
> the file-system location of the imported package directly inside the
> importing oneb how do I specify the location of the imported package in
> <xsl:use-package>, given that I would want the path to be relative to the
> importing stylesheet? Is the procedure for doing that the same as with
> <xsl:include> and <xsl:import>?
>
>
> Configuration files are an artefact of the Saxon implementation, nothing
> to do with the spec, which leaves the mechanism for locating a package
> implementation-dependent. You can't specify a relative path location for a
> used package (though, as I'm beginning to understand the JS common module
> system better, I think I can see how we could add that option). But there
> are alternatives to using a configuration file; you can use
> XsltCompiler.importPackage() in the s9api API, or the -lib option on the
> Transform command line.
>
>
> 3. On a semi-related topic, I want my function to have one-argument and
> two-argument versions. Since function parameters cannot be optional, I
> think a fairly straightforward way to do this would ge to put the code in
> the two-argument version, and have the one-argument version supply a
> default for the missing argument and then use it to pass the call along to
> the two-argument version. Is this the best way to deal with optional
> function arguments?
>
> Yes. (In my paper at XML Prague -- see
> http://www.saxonica.com/papers/xmlprague-2020mhk.pdf B'3.3) I proposed
> adding syntactic sugar to make this easier.)
>
> Michael Kay
> Saxonica
>
> XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
> EasyUnsubscribe <http://lists.mulberrytech.com/unsub/xsl-list/3318727> (by
> email <>)