This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Regarding the streamability of current(). In 19.8.9.3, we say (in a note) <quote> The effect of the rule is that expressions that use current as an operand with usage inspection are allowed (for example, name(current()) or current()/@class), but other operand usages fail. </quote> There's a problem here in that path expressions (like current()/@class) don't use the General Streamability Rules, and therefore don't define operand usage for their operands. It's not correct to imply that the LHS of a path expression has usage inspection. The *concept* of operand usage is defined for all operands of all expressions (see 19.4), and this section also states <quote> The assignment of operand usages to each operand role of each kind of construct is defined in 19.8 Classifying Constructs. </quote> But in fact we don't assign an operand role in all cases, including the common case cited here. (I came across this because I was trying to implement the rules for streaming current() in terms of operand usage, rather than using the normative algorithm in the spec, and it didn't work.)
The WG agreed to change the Note under "streamability of current()" to retain the examples of constructs that work, but to remove the reference to operand usage inspection; and to clarify the description of the concept of "operand usage" to make it clear that it is not defined for all constructs. The changes have been applied.