This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Static variables are local to a package (and can be compiled into a package). It is very reasonable to assumbe that, analogous to compiled languages, a given package will exist in a debug or tracing version, and a release version. The syntax of using packages currently is: <xsl:use-package name = uri package-version? = token > <!-- Content: (xsl:accept | xsl:override)* --> </xsl:use-package> The only way one can use a package conditionally is by using xsl:use-when with a static variable, say $DEBUG. This leads to the problem of having to fully copy all xsl:overrides and xsl:accepts, which, considering these can contain a fair amount of machinery, is not an ideal situation, let alone having to keep track of each change in both branches. A way to conditionally include packages without having to copy all overrides and accepts seems like a vital necessity with packaging. Ideas to solve this: - disconnect the child-parent relation of xsl:use-package and xsl:accept/override, placing them elsewhere (in which case some relation must exist between the package and what you override) - add children to use-package that specify the name and package-version, of which at most one can be effectively available. The second option seems the easiest of the two. Perhaps other options exist to resolve this.
We discussed this in Prague. There was some sentiment in the WG that the problem described here is real and that use-when is not always an elegant solution to it. Some WG members felt, however, that adjusting the dials on one's URI resolver (or catalog) would be an acceptable solution, which would require no new work. Among the ideas that arose: - make the @name and @version attributes on use-package take AVTs? - use general entities for the values - use namespaced twins for attributes, so @xsl_sc:name works the same as @name, but accepts a static expression as its value - use XQuery update on your stylesheet - use an XSLT stylesheet on your stylesheet We will need to come back to this.
I would like to pursue the general solution of providing a mirror for every attribute of every XSLT instruction which allows the value of the attribute to be computed by means of a static expression; the only exception would be attributes that are already static expressions, such as @use-when and xsl:variable[@static="yes"]/@select. It would include standard attributes such as default-collation on XSLT elements, but not on literal result elements. We should put these in a namespace, say compute for computed XSLT attribute; so for example <xsl:output compute:indent="if (system-property(x)=y) then 'yes' else 'no'"/> The attributes X and cxa:X would be mutually exclusive (static error if both are present). We wouldn't try to reflect this in the schema for XSLT; this is consistent with our treatment of use-when.
An alternative way forward, which would be potentially less disruptive, is to introduce static AVTs on all static attributes. It might look more natural to users that are already used to AVTs, it seems like a smaller change to apply and it doesn't change the schema. The downside is: how to tell the difference between a static AVT and a non-static one. But since currently there is no visual difference between a static and non-static attribute when no AVT is applied, this may be less a problem than it looks. Another downside is backward compatibility for attributes that currently accept paired accolades/curly braces as valid content.
I like the idea of static AVTs but it's not easy to find a good solution to the compatiblity problem. I propose: for any element in the XSLT namespace, for any permitted attribute A of that element that is in no-namespace there is another permitted attribute _A (the same attribute name, prefixed with an underscore), whose value is a static AVT for computing the value of A. If both A and _A are present, A is ignored. A static AVT is evaluated in the same way as an ordinary AVT, but using the rules for static expressions. For example <xsl:include _href="library_v{$version}.xsl"/> The result of evaluating a static AVT may be a dynamic AVT, but we won't go out of our way to make this easy. We allow the mechanism even for attributes with static significance, such as static="yes|no" and use-when. We won't include the extra attributes in the schema for XSLT 3.0 (we already ignore the implications of xsl:use-when processing). We won't allow the mechanism for xsl: prefixed attributes on literal result elements.
The WG decided to permit shadow attributes prefixed by an underscore as proposed in comment #4. This change has been applied to the spec.