This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 30244 - [XSLT30] Error XTSE0730 and the applicability of the streamable attribute and, in line with that, the visibility attribute
Summary: [XSLT30] Error XTSE0730 and the applicability of the streamable attribute and...
Status: NEW
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Recommendation
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-04-08 14:06 UTC by Abel Braaksma
Modified: 2019-02-15 17:14 UTC (History)
0 users

See Also:

Attachments

Description Abel Braaksma 2018-04-08 14:06:24 UTC 
Error XTSE0730 reads:

> If an xsl:attribute set element specifies streamable="yes" then every 
> attribute set referenced in its use-attribute-sets attribute (if present) 
> must also specify streamable="yes".
Which left me wondering, what happens in the converse situation, i.e., when an attribute-set with streamable="no" references one with streamable="yes".

My guess is that this is allowed (don't see any reason why not), but perhaps we ought to make that explicit?

Example:

<xsl:attribute-set name="x" streamable="yes">
   <xsl:attribute name="foo">bar</xsl:attribute>
</xsl:attribute>

<xsl:attribute-set name="y" attribute-sets="x" streamable="no"/>

-----

And while on the subject, I find the rules for streamability incomplete. I think the intent is clear, but I don't find it very explicit that the rules should be applied recursively:

> 1. Every xsl:attribute-set declaration for the attribute set has the 
> attribute streamable="yes".
At first I thought this meant all xsl:attribute-set declarations with the same name, but I think it means all the referenced declarations as well.

I'd like to suggest instead:

1. Every xsl:attribute-set with the same name has streamable="yes".

2. Every xsl:attribute-set declaration referenced through the use-attribute-sets attribute of each of the same-named attribute sets, has the attribute streamable="yes", recursively.

Or, perhaps simpler:

1. Every xsl:attribute-set declaration in the transitive membership of all declarations making up the attribute set has the attribute streamable="yes".
Comment 1 Michael Kay 2018-04-08 15:30:51 UTC 
Everything is allowed unless there is a rule saying it isn't.
Comment 2 Abel Braaksma 2018-04-08 17:42:27 UTC 
Yes, that makes sense. 

The 2nd part of my bug, I just realized it is a tad more confusing than I thought, at least to me. Because about visibility we say something similar, if one set has the visibility set, then:

> it [the attribute] must be present, with the same value, on every 
> xsl:attribute-set declaration making up the definition of that attribute set. 
Before that sentence, in 10.2.2, there's explicit talk about a set means all that share the same name ("all declarations within the same package sharing the same name").

So now I'm confused. I think these should be the rules:

1) Visibility: this is a property of a named attribute set. Used attribute sets aren't relevant and need not have the same visibility. Attribute sets with the same name must all have the same visibility, either implicitly or explicitly.

2) Streamability: when streamable="yes" then this applies both to all attribute sets with the same name *and* to all used attribute sets: the union of that set must each have the attribute streamable="yes".

I cannot ascertain with certainty that this is what the text says (so it is definitely implied).
Comment 3 Michael Kay 2019-02-15 17:14:48 UTC 
I don't think there's a bug here.

Firstly, streamable code can always be executed without streaming so there's no reason to think that a non-streamable attribute set shouldn't reference a streamable one, and the spec is clear that this is allowed because there's nothing to say that it isn't.

Secondly, your proposed rule 2 is redundant. We have already said that if A is streamable, then everything that it references must be streamable; we don't need to say it again.