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 have spent some time disentangling the rules on xsl:attribute-sets with regards to guaranteed streamability and I think we are missing some key point here. a) under 10.2.3 we say "considered as a seqtor" and then point to 19.8.6 where this precondition seems not to apply anymore b) under 19.8.6 Classifying Attribute Sets we say "usage transmission", but attribute sets are always grounded c) under 19.8.6 we don't say anything about the context posture d) section on xsl:element classifies @use-attribute-sets with usage absorption, this seems to not make sense I think all of these can be fixed by treating the streamability similar to other declarations (i.e., accumulators and stylesheet functions) where the direction of streaming is not known beforehand. Suggestions: 1) Under 10.2.3. item (2): every xsl:attribute-set has motionless sweep and grounded posture according to the rules in Classifying Attribute Sets 2) Under 19.8.6.: remove the reliability on the general streamability rules 3) Under 19.8.6.: Change the text to something like (all apply): i) The posture of an attribute set is grounded ii) The sweep of an attribute set is motionless if all xsl:attribute instructions are motionless according to the streamability rules on xsl:attribute with the context posture set to striding. iii) Otherwise free-ranging. 4) Under 19.8.6: add in a Note that all referenced attribute sets must have streamable="yes" and abide by those rules, and/or point back to 10.2.3. 5) Replace any place where @use-attribute-sets is mentioned in the streamability rules and (perhaps) point to the section on Classifying Attribute Sets. I don't think they should have a usage, but if any, the usage is inspection and have themselves no additional operands, as they are not allowed to "absorb" any node.
a) under 10.2.3 we say "considered as a seqtor" and then point to 19.8.6 where this precondition seems not to apply anymore Agreed. Delete "considered as a sequence constructor". b) under 19.8.6 Classifying Attribute Sets we say "usage transmission", but attribute sets are always grounded Under the GSR, I think operand usage is irrelevant if the operand is grounded. So this doesn't actually matter; but using "absorption" might be clearer. c) under 19.8.6 we don't say anything about the context posture True, and this could potentially be a difficulty, which your proposal eliminates d) section on xsl:element classifies @use-attribute-sets with usage absorption, this seems to not make sense Again, the attribute set is grounded, so the operand usage does not make much difference. I think all of these can be fixed by treating the streamability similar to other declarations (i.e., accumulators and stylesheet functions) where the direction of streaming is not known beforehand. Suggestions: 1) Under 10.2.3. item (2): every xsl:attribute-set has motionless sweep and grounded posture according to the rules in Classifying Attribute Sets Yes. 2) Under 19.8.6.: remove the reliability on the general streamability rules Interesting... 3) Under 19.8.6.: Change the text to something like (all apply): i) The posture of an attribute set is grounded ii) The sweep of an attribute set is motionless if all xsl:attribute instructions are motionless according to the streamability rules on xsl:attribute with the context posture set to striding. iii) Otherwise free-ranging. This drops the current possibility for an attribute-set to be consuming. I think that's probably a useful simplification, since it's very hard to think of practical use-cases where people would want this, and those use-cases can always be achieved by replacing the attribute-set with a streamable template rule. 4) Under 19.8.6: add in a Note that all referenced attribute sets must have streamable="yes" and abide by those rules, and/or point back to 10.2.3. 5) Replace any place where @use-attribute-sets is mentioned in the streamability rules and (perhaps) point to the section on Classifying Attribute Sets. I don't think they should have a usage, but if any, the usage is inspection and have themselves no additional operands, as they are not allowed to "absorb" any node. OK, I think that probably works.
> This drops the current possibility for an attribute-set to be consuming. I > think that's probably a useful simplification, Agreed. There's a myriad of other ways to achieve this. Furthermore, this simplifies overriding as a processor will know beforehand that an attribute set is never going to consume and can inline the code without worrying about streamability issues. > I don't think they should have a usage, but if any, the usage is inspection and > have themselves no additional operands, as they are not allowed to "absorb" any > node. My stance is now that they can be removed from the operands (perhaps with a Note), or alternatively, as we do with some other non-relevant (i.e., always grounded) operands, add a note that this or that is the operand usage and role, but that it does not influence the analysis.
The changes were agreed and have been applied.