This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 28114 - [xslt 3.0] Cycles in attribute sets
Summary: [xslt 3.0] Cycles in attribute sets
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Candidate Recommendation
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-28 21:16 UTC by Michael Kay
Modified: 2015-10-29 09:50 UTC (History)
1 user (show)

See Also:


Attachments

Description Michael Kay 2015-02-28 21:16:31 UTC

    
Comment 1 Michael Kay 2015-02-28 21:24:36 UTC
We say in 10.2.2

<quote>
Cycles in attribute sets (that is, where an attribute set directly or indirectly invokes itself) are not permitted, and are detected statically.

An attribute set A is dependent on an attribute set B if A contains an attribute set invocation that is bound to B, or if A contains an attribute set invocation that is bound to an attribute set C that is dependent on B. A cycle exists if any attribute set is dependent on itself.

Such a cycle is an error even if the attribute set is never invoked, and even if the cycle is subsequently broken by overriding one or more of the attribute sets participating in the cycle. As a consequence, it is possible to detect a cycle during the static analysis of a package, before it is known how the package will be used.
</quote>

The problem here is that an attribute set invocation is not bound statically to an attribute set; our only definition of such binding occurs when packages are assembled, and takes overrides into account. We could define some kind of concept of binding within the scope of a single package, but it's not clear how it would handle references to attribute sets in a used package.

In 9.11 we have a more general treatment of circularities among component definitions, which includes attribute sets within its scopy, and which deems all circularities to be dynamic errors, to avoid the kind of problems referred to above.

I suggest we simply delete section 10.2.2, and rely on the general mechanisms in 9.11.
Comment 2 Michael Kay 2015-03-02 11:37:57 UTC
Note also in 10.2.2 we say:

<quote>
Circularity is not the same as recursion. Stylesheet functions (see 10.3 Stylesheet Functions) and named templates (see 10.1 Named Templates) may call other functions and named templates without restriction.
</quote>

This seems unclear as regards recursion in attribute set declarations. Consider:

<xsl:attribute-set name="a">
  <xsl:attribute name="x">
    <xsl:variable name="v">
      <e xsl:use-attribute-set="a">value</e>
    </xsl:variable>
    <xsl:value-of select="serialize($v)"/>
  </xsl:attribute>
</xsl:attribute-set>

It's a pretty obscure corner case, but if we want to be rigorous we should have a view on whether the above is a disallowed circularity or an allowed recursion.
Comment 3 Michael Kay 2015-03-02 17:44:41 UTC
Looking at the case in comment #2 more closely, note that XSLT 2.0 said only:

[ERR XTSE0720] It is a static error if an xsl:attribute-set element directly or indirectly references itself via the names contained in the use-attribute-sets attribute.

So the kind of recursion described in comment #2 was not disallowed by this rule. It's not clear whether it was disallowed by the general rules on "circular definitions". I'd be inclined to say it falls into the same category as function or template recursion, and if it's non-terminating, there's no guarantee it will be handled tidily.
Comment 4 Abel Braaksma 2015-03-15 12:47:00 UTC
> So the kind of recursion described in comment #2 was not disallowed by this 
> rule.

and from the spec:
> A cycle exists if any attribute set is dependent on itself.

and:
> [ERR XTSE0720] [..] an xsl:attribute-set element directly or indirectly 
> references itself via the names contained in the use-attribute-sets attribute.

I think that the example in comment#2 indirectly references itself (through $v)  and that it is dependent on itself. So it is my understanding of the spec that this is disallowed.

But I don't see how it can be a static-only error, as already explained in comment#1.

> and if it's non-terminating, there's no guarantee it will be handled tidily.

I can think of only one example (also very corner-casy) that might be terminating, based on the non-deterministic behavior of streams, something along those lines:

<xsl:attribute-set name="a">
  <xsl:attribute name="x">

    <xsl:variable name="t" as="xs:time">
      <xsl:stream href="urn:current-time">
          <xsl:copy-of select="/time/@current-time" />
      </xsl:stream>
    </xsl:variable>

    <xsl:variable name="test">
      <xsl:if test="$t lt xs:time('10:23:00')">
        <time xsl:use-attribute-sets="a">
          <xsl:value-of select="$t"/>
        </time>
      </xsl:if>
    </xsl:variable>

    <xsl:value-of select="$test" />
  </xsl:attribute>
</xsl:attribute-set>

This would loop recursively until the time is 10:23. Using this attribute-set would, if it were allowed, halt processing until that time is reached, though I am not sure whether the variable would yield a new value on each evaluation as a result of the xsl:stream instruction, I think that would be implementation defined (?).
Comment 5 Michael Kay 2015-03-20 10:22:32 UTC
The WG decided that cycles in attribute set declarations should be handled under the general rules for circularities, and that this should apply even to those edge cases where the self-reference might be considered to represent legitimate recursion. The changes have been applied to the spec.