22933 2013-08-13 08:45:16 +0000 [XSLT 3.0] Streamability rules: Simple Mapping Expressions 2014-05-15 14:00:39 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Working drafts PC All CLOSED FIXED P2 normal --- 1 mike mike public-qt-comments oldest_to_newest 91970 0 mike 2013-08-13 08:45:16 +0000 Since the streamability rules were written the XPath 3.0 grammar has changed so there is now a separate production for SimpleMapExpr. The semantics of a SimpleMapExpr are identical to the semantics of xsl:for-each, so it should be possible to use the same streamability rules without change. 91972 1 mike 2013-08-13 10:01:42 +0000 "Should be possible" - indeed. There is also a clear relationship to the rules for RelativePathExpr. This gives us an opportunity to examine why the rules for xsl:for-each and for RelativePathExpr are different. Let's look at the cases in turn. 1. For path expressions, we have the rule: If either operand is a ContextItemExpr or a ForwardStep using the self axis, followed in either case by zero or more motionless predicates, then the sweep of the other operand; which has no equivalent for xsl:for-each. It's very unlikely to arise with xsl:for-each, but does that mean we should leave it out? It certainly needs to be there for "!". 2. For RelativePathExpr we have the rule If the first operand is motionless, then motionless; For xsl:for-each the corresponding rule has additional qualifications: the first relates to xsl:sort, which is a reasonable difference, and the second relates to the use of group binding variables. This qualification is also relevant to path expressions. However, I think it can be simplified. I think there's another bug here. Consider the expression (1 to 10)/current(). The first operand is motionless so we deem the expression as a whole motionless, regardless of the fact that current() is free-ranging. The issue here is that there are a small number of constructs, including current(), current-group(), and references to group binding variables, that can appear on the rhs of "/" (or in the body of xsl:for-each) and depend on the "outer context" rather than the "inner context" of the expression. So I think this rule for RelativePathExpr needs to disallow references to grouping variables and to current() on the rhs. 3. Under RelativePathExpr rule 3, we have: If the syntactic context is an inspection context and the RelativePathExpr takes the form of a RelativePathExprP that itself conforms to the rules for a motionless pattern (see 19.3.10 Classifying Patterns), then consuming; Clearly there's no direct equivalent for xsl:for-each because an xsl:for-each instruction cannot take the form of a pattern. It's an odd rule though, especially as the example given - exists(descendant::section) - isn't even a RelativePathExpr according to the way we defined it. Somehow one feels this rule shouldn't be necessary; it should fall out from the other rules. 4. Under xsl:for-each rule 3, we recognize group-consuming constructs of the form <xsl:for-each select="$current-group"><xsl:value-of select="child"/></xsl:for-each> We don't have any corresponding rule to recognize $current-group/string(child) as group-consuming; I can't see any good reason not to. 5. Rule 4 of RelativePathExpr and Rule 4 of xsl:for-each have similar effect but they are phrased differently and are not in fact equivalent. For example, the xsl:for-each rule recognizes <xsl:for-each select="a/b/c"><xsl:sequence select="name()"/></xsl:for-each> but the RelativePathExpr rule does not allow a/b/c/name(). I think these two rules should be aligned. 94836 2 mike 2013-10-16 14:29:46 +0000 The rewrite of the streamability rules following the Henley face-to-face means that this bug report is no longer relevant.