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 7356 - [XSLT 2.0] Need clarification in the definition of circularity
Summary: [XSLT 2.0] Need clarification in the definition of circularity
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 2.0 (show other bugs)
Version: Recommendation
Hardware: All All
: P2 major
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL: http://www.w3.org/TR/xslt20/#dt-circu...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-08-17 21:25 UTC by Henry Zongaro
Modified: 2010-07-27 20:40 UTC (History)
1 user (show)

See Also:


Attachments

Description Henry Zongaro 2009-08-17 21:25:59 UTC
The definition of circularity in XSLT 2.0[1] is "A circularity is said to exist if a construct such as a global variable, an attribute set, or a key is defined in terms of itself. For example, if the expression or sequence constructor  specifying the value of a global variable X references a global variable Y, then the value for Y must be computed before the value of X. A circularity exists if it is impossible to do this for all global variable definitions."

The error reported for a circularity is "[ERR XTDE0640] In general, a circularity in a stylesheet is a non-recoverable dynamic error. However, as with all other dynamic errors, an implementation will signal the error only if it actually executes the instructions and expressions that participate in the circularity."

It's not clear from the definition or the examples whether circularity is a static property of a variable or key, or it is something that is dynamic.  Consider the following example:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0">
  <xsl:param name="p" as="xs:boolean"/>
  <xsl:variable name="x" select="if $p then $y+1 else 17"/>
  <xsl:variable name="y" select="if $p then 19 else $x"/>

  <xsl:template match="/">
    <out><xsl:sequence select="$x, $y"/></out>
  </xsl:template>
</xsl:stylesheet>

In this example, there is a variable reference for x in the expression used to define y, and a variable reference for y in the expression used to define x.  If these are "references" for the purposes of the definition of circularity, then x must be computed before y, and y before x, and so there is a circularity.

However, if a reference for the purposes of circularity means a reference that is actually evaluated, then there is no circularity - if p has the value true, the definition of x has a reference to y, but the definition of y does not have a reference to x, so y must be evaluated before x if p is true; if p has the value false, the definition of y has a reference to x, but the definition of x does not have a reference to y, so x must be evaluated before y if p is false.

[1] http://www.w3.org/TR/xslt20/#dt-circularity
Comment 1 Henry Zongaro 2009-08-18 01:34:41 UTC
Sorry - I forgot to tie that back to error XTDE0640.  With the static view of what is considered a circularity, the "if-then-else" expressions in the select attributes of the two variables, in their entirety, would be considered "instructions and expressions that participate in the circularity."  With the dynamic view, the "instructions and expressions that participate in the circularity" would be only those that actually cause a variable to be referenced in evaluating that same variable.

I think the dynamic view of circularity was intended, otherwise it makes it unnecessarily awkward to have the definition of a global variable use an xsl:apply-templates instruction, for instance.  However, neither the definition nor the examples make that clear.
Comment 2 Michael Kay 2010-07-15 08:45:23 UTC
The WG looked at this.

We propose to make no change for 2.0: the spec clearly states that this is a dynamic error, triggered only if the expressions causing the circularity are actually evaluated.

For 2.1/3.0 we decided to allow implementations to raise a static error in respect of a cycle of statically-determined references (e.g between functions, variables, named templates and keys) irrespective of whether they are actually evaluated.

Needs drafting for 3.0.
Comment 3 Henry Zongaro 2010-07-15 16:48:31 UTC
May I ask for a clarification on what will happen in XSLT 3.0?  Would a processor be permitted to report a static error in the case of the potential circularity I described in comment #0?  Or required to report one?
Comment 4 Michael Kay 2010-07-15 18:48:50 UTC
My interpretation of the direction was that we would allow this to be reported as a static error, but not require it. Some circularities (those involving xsl:apply-templates) can only be detected dynamically, so this would still be allowed.
Comment 5 Sharon Adler 2010-07-27 20:39:30 UTC
See 15 July 2010 Minutes - resolution was: do nothing for 2.0; for next version, allow implementations to raise a static error in respect of a cycle of statically determined references without proving that they will inevitably be evaluated.