This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
It seems that the expression (@a, @b) is not guaranteed streamable. The general streamability rules apply. Both operands have U=transmission, P=striding, S=motionless. The adjusted usage and adjusted sweep are the same as U and S. Under 1.c.ii both operands are potentially consuming. Therefore 2.c.ii applies, and the expression as a whole is roaming and free-ranging. There seems to be a need for another subrule of 2.c to say that if all the "potentially consuming" operands are motionless and if all have the same posture P, then the expression is motionless with posture P.
There's a potential subtlety that we may need to carefully examine if we are making this change (which in principal seems a sound one), consider: (self::p, @lang) - both striding and motionless - potentially consuming - with new rule, this remains motionless and striding string((self::p, @lang)) - inner expr is motionless and striding - under 1.b.iii.A we say: if type U is not element/document, then U' is inspection After this proposed change, the above expression hits an ambiguity, as there is no more "a type", but there is now a "collection of types" (attribute and element nodes), of which one would yield U' inspection, and the other would yield U' absorption. Obviously, the result of string((self::p, @lang)) must be consuming (and streamable). I *think* that this is covered under 19.2 Determining the Static Type of a Construct, but in the GSR we speak of "The static type T", while in fact this is a union of several types. Perhaps that under 1.a.i. we could remove this ambiguity by not talking of a static type T, but of determining the union U{t1, t2...} of the construct.
>After this proposed change, the above expression hits an ambiguity, as there is no more "a type", but there is now a "collection of types" (attribute and element nodes), of which one would yield U' inspection, and the other would yield U' absorption. In fact, the static type of an operand is by definition a U-Type, and the U-Type of (self::p, @lang) is U{element(), attribute()}. The intersection of this with U{element(), document-node()} is NOT U{}, therefore U' is U. I think there is no ambiguity. >in the GSR we speak of "The static type T", while in fact this is a union of several types The definition of the "static type" of an expression says that it is a U-Type. Would it be clearer if we called it the "static U-Type" of an expression?
(In reply to Michael Kay from comment #2) > > In fact, the static type of an operand is by definition a U-Type, and the > U-Type of (self::p, @lang) is U{element(), attribute()}. The intersection of > this with U{element(), document-node()} is NOT U{}, therefore U' is U. I > think there is no ambiguity. On a fresh new read of spec and proposed changes, I think you are right. My issue was with "the static type of X" which is not "a type" but defined as a union of types. The ambiguity was in my head, not in the (literal) reading of the spec. > > >in the GSR we speak of "The static type T", while in fact this is > >a union of several types > > The definition of the "static type" of an expression says that it is a > U-Type. Would it be clearer if we called it the "static U-Type" of an > expression? Yes, I think this makes sense. It would make for a clearer read of U-type related parts of the spec. Or perhaps instead of calling it a static type, we should just always call it the U-type, as the words "static type" can easily be confused with the declared type of a declaration or expression.
The proposal was accepted. Changes to clarify that static type is a U-type were left at the editor's discretion.