This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Under the definition of Guaranteed Streamable we give three options what a processor MUST do when a declared streamable construct is not guaranteed streamable: a) Signal a static error b) Process the stylesheet as if it were a non-streaming processor c) Process the stylesheet with streaming if it is able to do so, or signal a static error if it is not able to do so. For (b) and (c), I think it is appropriate that we specify that the processor must signal a warning (which can be switched off). Otherwise, we end up with stylesheets that are not guaranteed streamable and users never knowing they are not guaranteed streamable, hence undermining the meaning of guaranteed streamability. Also, we don't specify a default option if the user does not specify a specific option. I think the default option should be to signal a static error and at user option, this can be changed.
In general we have avoided being prescriptive about warnings, and in the few cases where we have specified that processors must give a warning (for example, when running a 1.0 stylesheet under a 2.0 processor), it has not been a success: users lobbied hard for an option to suppress this warning, and I eventually provided an option to suppress it, although it's not clear that the spec allows me to do so. There are also some environments (e.g. XSLT in the browser) where providing a warning is difficult to achieve. And one can satisfy the letter of the requirement without satisfying its spirit by writing the warning to some system log file that no-one ever looks at. I think in general it's best to leave implementors to decide when warnings are appropriate.
We discussed this in Prague. There was some sentiment against requiring warnings in cases b) and c); it gets too far into the design of the user interface. Some expressed the sentiment that the crucial requirement was that the user be able to require a signal, as in case a); warnings in the other cases were not essential. MK pointed out that for Saxon, option a) requires turning optimization off; the consequence is that when options b) and c) are chosen, the streaming analysis will not actually be 100% compatible with the analysis prescribed by the spec. After discussion, ABr said he was not inclined to pursue it further.