Saxon

I have produced an initial implementation of this feature.

The attribute saxon:documentation-prefixes can be used on the outermost element of the top-level module in a package; it applies to the whole package. The value is a whitespace-separated list of namespace prefixes (which must be declared). If a prefix is in the list, then the corresponding (prefix, uri) pair cannot be used for the names of stylesheet objects such as variables, functions, and templates; and is not part of the static context for XPath expressions. It is therefore not included in SEF export files.

We almost certainly need in-scope namespaces in the expression tree for compile-time operations; the time to get rid of them when not needed is probably when exporting the expression tree to a SEF file.

I did an experiment running the XSLT30 test suite with -export:on, having patched the code to stop outputting the "ns" attribute in the SEF file entirely. This causes 1259 out of 11476 tests to fail. Main causes of failure:

• function calls like accumulator-after/before, system-property, key, format-number that take a lexical QName as an argument. (Note, in the vast majority of cases the argument is supplied as a string literal anyway; in other case it can be supplied as an EQName to remove the dependency).

• for literal result elements, we generate a "namespaces" attribute in the SEF containing namespaces to be included in the result tree; these rely on the "ns" attribute containing the relevant bindings

Looking at the detail, we (specifically, the XJ compiler) are outputting an "ns" attribute for any expression whose static namespace context differs from its parent element; generally this means there is one ns attribute on the top-level expression for each component, which is perfectly acceptable. There is one exceptions, we seem to be generating an ns attribute unconditionally on calls to system functions that depend on the static context. This looks redundant to me.

The XX compiler is generating far more "ns" attributes: the problem is the cost of comparing the namespace context of an element with that of its parent to decide that they are the same, which is probably greater than the cost of just generating the attribute unconditionally.

I've done work to reduce this with a call on an extension function saxon:has-local-namespaces() to test whether a child element has namespaces different from the parent, but I'm not convinced it's doing a good job yet.

After further thought, I'm inclined to the following.

Add two extension attributes which can (only) be used on the outermost element of the top-level module in a stylesheet package:

saxon:static-namespaces defines the namespaces that are available during static processing of the stylesheet. The value is a set of prefixes (or #default, or #all) which expands to a set of (prefix=uri) bindings using the namespace declarations on the containing element. This set of namespaces is used for all static resolution of lexical QNames (and other namespace prefixes) throughout the package. This includes names used in the declaration of stylesheet components such as functions, templates, variables, and modes; names used in all XPath expressions and patterns; prefixes used in @extension-element-prefixes, @exclude-result-prefixes, and xsl:namespace-alias; and names used in QName-valued arguments of functions such as function-available, system-property, format-number, key, and accumulator-before/after, provided they appear as string literals in a static call of the function. They do not, of course, affect the resolution of literal result element or attribute names, which are resolve by the XML parser in the usual way.

saxon:dynamic-namespaces defines the namespaces that are available during execution of the stylesheet. This must be a subset of the static namespaces. By default, all static namespaces are available. The namespaces in this list are used to provide the default namespace context for xsl:evaluate (in the absence of a namespace-context attribute); when casting from string to QName; and for dynamic calls to functions such as function-available, accumulator-before/after, etc. In addition, a namespace that is not present in the list automatically becomes an "excluded" namespace for the purpose of literal result elements (that is, it is not copied to result elements created using an LRE). For a great many stylesheets, setting saxon:dynamic-namespaces="" (an empty set of bindings) will be quite appropriate.

The advantages of using these attributes are:

(a) a single set of namespaces is established for use throughout the stylesheet. It is no longer necessary, for example, to declare prefixes used in variable or function names in every module that contains such a reference; they are effectively declared once, at the package level.

(b) the compiler is freed from the burden of maintaining lots of different namespace contexts when performing rewrites such as function inlining. Because all expressions have the same static namespace context, it only has to be recorded once at the root of the expression tree.

(c) the number of namespaces copied into the SEF file is greatly reduced, which reduces the size of the file an improves speed of loading. Most of the namespaces that currently appear in SEF files are never used. (Note that names of components such as variable and functions, and references thereto, will always appear in the SEF file as EQNames; therefore namespace bindings that allocate a prefix to these namespaces are not needed.)