This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I think we can add another rule for xsl:try, between rule 1 and 2: 1. .. current rule ... 2. If the highest sweep of each the choice operand group of all xsl:catch elements is consuming, and the posture and sweep of the select and/or sequence constructor of xsl:try are grounded and motionless then the combined posture of the choice operand group and a sweep of consuming. 3. Otherwise, roaming and free-ranging This allows us to write: <xsl:try> <xsl:value-of select="10 div @amount" /> <xsl:catch> <xsl:message select="copy-of(.)" /> </xsl:catch> </xsl:try>
We discussed this in Prague. There was some skepticism about using catch clauses for normal, rather than exceptional, processing. But on balance we decided that it would be more consistent with our practice elsewhere to make the catch elements a choice operand group, and to allow the choice operand group to consume input if the try does not. If we're going to allow it, we can refer to the general streamability rules, rather than by spelling the rules out in detail as in the bug report.
I've looked at this and I don't think it's worth the effort of complicating the rules for this case. I just can't see a practical use case where the user would want to write a motionless try expression, with a consuming catch expression. I propose closing as WONTFIX.
I think it is worthwhile to go over the motivation behind this change, as on last telcon, several members, including me, found disallowing streaming in such scenarios too pedantic towards users. A non-conclusive list of arguments in favor of this change, in no particular order: 1. Orthogonality with xsl:choose, which has an almost similar structure, and uses the choice operand group. 2. While using try/catch for branching is not considered a good programming practice, it is in common use in programming languages that support try/catch, henceforth, we should not force people to change their programming habits when they require streaming for try/catch. 3. In cases where the try-part introduces new streaming, or a grounded expression, the catch-part cannot currently consume the streamed node. This is a potential use-case that is not easily possible without this rule: <xsl:try> <xsl:stream href="@source"> <xsl:apply-templates /> </xsl:stream> <xsl:catch> <error for-file="{@source}"> <xsl:copy-of select="." /> </error> </xsl:catch> </xsl:try> 4. The change is minimal and does not introduce new features, it merely finetunes the rules and makes them more consistent. 5. Anything else I forgot? ;)
The WG decided on 2014-03-06 to accept Abel's proposal. In email correspondence Abel and I concluded that the resulting rules are equivalent to invoking the general streamability rules with appropriate operand usages. I will therefore implement the proposal with that reformulation.