[Bug 24478] New: [xslt 3.0] Static variables and import precedence

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24478

            Bug ID: 24478
           Summary: [xslt 3.0] Static variables and import precedence
           Product: XPath / XQuery / XSLT
           Version: Last Call drafts
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSLT 3.0
          Assignee: mike@saxonica.com
          Reporter: mike@saxonica.com
        QA Contact: public-qt-comments@w3.org

Our rules for the scope of static variables turn out to have some unfortunate
consequences. Consider the following:

<xsl:variable name="DEBUG" static="yes" select="false()"/>
<xsl:import href="common.xsl"/>
<xsl:variable name="DEBUG" static="yes" select="true()"/>
<xsl:import href="common.xsl"/>

where common.xsl includes something like

<xsl:assert .... use-when="$DEBUG"/>

The effect is that the use-when expressions in the two occurrences of
common.xsl can have different values. This effectively means that we need to
recompile common.xsl every time it appears, which is a significant performance
regression from 2.0 for those stylesheets that contain multiple imports of the
same module. There are some widely used stylesheets out there that import a
common.xsl module 30 or 40 times, so the effect is significant.

(Note, this situation could arise even if we still had the rule that "imports
must come first". Just replace the imports above by an include of a module that
does nothing other than to import common.xsl).

I would like to suggest a different rule which avoids this problem but removes
very little useful functionality.

We define an order of declarations in which, effectively, xsl:include and
xsl:import are expanded inline. (This is an extension to the current
"declaration order" that treats import the same way as include). Then for
static variables, if multiple declarations of the same variable name are
encountered, we use the FIRST one encountered, and use it consistently
throughout the entire stylesheet (package).

This behaves in the same way as at present in that parent modules override
their child modules in the import tree, but it works differently for sibling
imports: it is now the first import that counts, rather than the last. I think
that overriding declarations in preceding-sibling modules is relatively
uncommon and not especially useful, so I think this is a small price to pay for
the benefits that we get if a static variable has the same value throughout the
compilation of a package.

The new rule applies only to static expressions (that is, use-when); variable
references in dynamic expressions are unaffected.

The rule introduces an inconsistency between static and dynamic variable
references; but the rules for these two cases are already inconsistent. And in
one respect they become more consistent, in that it will now be true in both
cases that a given variable has a single value throughout the package.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 3 February 2014 07:20:27 UTC