This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
As XSLT applications become larger, there is a requirement for separate compilation of stylesheet modules. The design of XSLT 2.0 makes this difficult because there are so few constraints on what an importing/including stylesheet can do to change the behaviour of an imported/included stylesheet. Some of the changes that are needed to make separate compilation viable include: (a) some change to the syntax and/or semantics of xsl:include and xsl:import to recognize the existence of precompiled stylesheet modules (b) addition of attributes controlling visibility of the declarations of functions, named templates, global variables and other objects such as attribute sets in a precompiled module, for example: public=yes|no, final=yes|no. Perhaps requiring override=yes in an overriding declaration to make it clear that the overriding stylesheet knows what it is doing. (c) rules constraining the ability to override variables, templates and functions: for example, requiring the type signature of the overriding object to be compatible with that of the object that it overrides; disallowing overriding a variable with a param; disallowing the relaxation of a required=yes constraint or changing of tunnel=yes|no; requiring all variable, function, and template references within a module to be satisfied within that module (perhaps by a declaration defined with abstract=yes) (d) some kind of connection between importing and modes: for example the ability while importing a module to alias its modes, to prevent unintended interference between the modes used in different stylesheet modules. Perhaps the ability to declare a mode as final. (e) making some declarations such as xsl:strip-space and xsl:output less global: for example these declarations when used in a compiled module might be defined to apply only to calls on document() or xsl:result-document within that module.
Some further design ideas to meet this requirement: Allow a stylesheet module to specify library="yes|no", default is "no". If library="yes" is specified, then the idea is that it is suitable for separate compilation (along with the modules that it includes or imports). In a library module: (a) you cannot use the context node when initializing global variables (b) you must declare which global variables, functions, named templates, and attribute sets are visible outside the module by use of the attribute public="yes" (c) all references to variables, functions, named templates etc must be satisfied within the module (or the modules it imports/includes); they cannot refer to variables etc supplied by the caller. However we allow them to be satisfied by a variable, function etc declared with abstract="yes", in which case the caller must supply a concrete implementation. (d) in all public variables, functions, and templates, all types ("as" attributes) must be explicit. (e) a public object can be declared with final="yes" to prevent it being overridden (f) a mode can also be declared with final="yes". The calling stylesheet cannot provide template rules in such a mode. A mode declared with public="no" cannot be invoked from outside the library. (g) when overriding a public variable, function, or named template, the overriding object must (i) declare override="yes", (ii) have a compatible signature. This means the parameter types and return type must be compatible (details TBA), required parameters cannot be made optional, and so on. (h) constructs such as xsl:decimal-format, xsl:key, xsl:namespace-alias are non-overridable: if a value is declared in a library module, that value is used in the library module, regardless of anything the caller declares.
Comment by Dimitre Novatchev on the xsl-list (today) This proposal is extremely important. Its incorporation into XSLT 2.1 would provide the capability to have separately compiled libraries (as opposed to a main stylesheet == "separate application") of functions. I have a remark about making sure a specific mode in the module cannot accidentally be selected (this is not the same as overriden !) by an external template with mode="#all" The existing text ( (d) in the Description, and (f) in the second post by Dr. Kay) does not rule out such a possibility. In particular, there is a need that a mode with a name defined in the module be accessible, but only *by name*, to exteranal <xsl:apply-templates> instructions. At the same time, any external <xsl:template> that has mode ="#all" should not be available for selection in a mode defined in the specific module.
At its telecon of 18 November 2010,[1] the XSL WG discussed the status of this enhancement request. MK summarized discussion from F2F meeting of 2 November 2010[2] Discussion of notion of compilation unit, and an import mechanism - similar to, but not same as, xsl:import/xsl:include. Overriding only ever occurs by importer itself. Conflicts result in an error. Looked at functions and named templates to begin. Looked at visibility of these - a single attribute with four values: abstract, public and overridable, public and non-overridable, private. Settled on names "abstract", "public", "final" and "private". Looked at rules for overriding functions and named templates in terms of signatures. Decided signatures must be the same. Open item: Should overriding templates be permitted to add parameters with default values? Discussion of overriding and interaction with existing override attribute of xsl:function. Final conclusion was that current semantics for override would probably have been better handled by xsl:use-when. Global variables and parameters. Raised issue of two users importing the same "package". Do they get the same variables (and functions) or different? If two packages import the same third package, they can do so with different settings of global variables. HZ: Minutes of F2F meeting seem to indicate that point hadn't been settled. MK: My recollection was that there was more consensus on that than minutes reflect. Open item: Will global variables be permitted to have different settings in different importing units? Open item: Relationship of separate compilation and schemas is a big open issue. DN: I think the issue of being able to selectively import objects from a package is an important usability question. No decision on this point. DN: I don't think we should use the term "compilation unit." Can imagine we might want to have packages that are not compiled, for instance. Don't want to imply that the packages are compiled. JS: It hasn't ever been about compilation for me. There are other things besides being able to separately compile that are enabled by this facility. SCA: It is related a lot to modularization and segmenting of code. We don't have a lot of good terms left. DN: Should a package namespace be forbidden to be used in importing code, except for overriding? Might help to avoid mistakes. DN: Could also introduce scope/visibility for objects in imported stylesheet modules, not just packages. For backwards compatibility, default scope would be public. No decision was made on these last two points. [1] http://lists.w3.org/Archives/Member/w3c-xsl-wg/2010Nov/0042.html (Member-only link) [2] http://www.w3.org/XML/Group/2010/11/xsl-ftf-minutes.xml (Member-only link)
Resolved at the Prague F2F March 2011 to close this as we now have a design intended to meet this requirement.