RE: source-document/@use-accumulators

(note: previous discussion was accidentally on the member only list, starting here: https://lists.w3.org/Archives/Member/w3c-xsl-wg/2016Aug/0005.html)

In light of yesterday's discussion, I've taken a (long) moment to check what we currently say about @use-accumulators, why they are there and how they are applied.

Let's revisit the rationale for a moment: As described in a Note under 18.2.2: @use-accumulators is not only for performance. A real problem arises when an accumulator (may) raise a dynamic error, send a message or raises assertions. Since with streaming, an accumulator has to be pro-actively calculated for every node it applies to, it is simply not feasible to allow (by default) all accumulators on streamed nodes.

After writing up the above summary (which I hope removes what I think MSMcQ expressed as feeling not at ease with the semantic distinction between handling streamed and non-streamed nodes), I set out to find a solid reasoning why, given the current state of the spec, I thought applying @use-accumulators to non-streamed documents to be a bad idea, or a non-enforceable one.

I changed my mind. In fact, I think now that the inverse is true. 

Rationale:

One of the ideas behind introducing xsl:source-document was to allow easy testing of your code in a non-streaming way, or writing up code that can be used with both streaming and non-streaming processors.

A certain set of potential errors, i.e. with using accumulators that are not applicable if you "switch" from streamable=no to streamable=yes, would not be apparent.

Furthermore, I wasn't aware that we already have a rule in place that restricts the set of applicable accumulators (see 18.2.2) for results of xsl:copy-of, fn:copy and fn:snapshot, and the implicit snapshot of xsl:merge.

My suggestion in last telcon to raise an error when @use-accumulators is present and streamable=no is also present bears no ground: you would lose the ability to switch between streaming and non-streaming, as we cannot use shadow attributes to magically have an attribute disappear.

Proposal:

Therefore, I now propose that we follow Michael Kay's suggestion to have @use-accumulators apply equally with xsl:source-document/@streamable="yes" or "no". 

In addition, I propose to drop this very same restriction from xsl:merge-source, in much the same way that, if present, it must be enforced. This then serves the same purpose as xsl:source-document, in that it allows you to switch between streaming mode and non-streaming mode by simply flipping the @streamable attribute.

All in all, this seems to be in line with what we already enforce for non-streaming processors:

" However, a non-streaming processor MUST enforce the constraint implied by a use-accumulators attribute restricting which accumulators can be used with a particular document."

This day's reading through the spec on accumulators led to a few bugs, some related, some not, which I have raised in BugZilla. For this particular issue, I raised bugs 29804 and 29805 respectively.

Cheers,
Abel


> -----Original Message-----
> From: Abel Braaksma [mailto:abel.braaksma@xs4all.nl]
> Sent: Friday, August 26, 2016 8:56 AM
> To: 'Michael Kay'; 'XSL Working Group'
> Subject: RE: source-document/@use-accumulators
> 
> I'm inclined to suggest the inverse, mainly because we introduced @use-
> accumulators *only* for streaming (to limit the cost of applying each and
> every accumulator for streams) and because that's how it works elsewhere.
> 
> For instance, it would be orthogonal with how xsl:merge-source/@use-
> accumulators works. In fact, we even introduced a specific error there,
> XTSE3195, if someone tries to use @use-accumulators with something that is
> not streaming, quote: "If the use-accumulators attribute is present then the
> for-each-stream attribute must be present.".
> 
> I believe that is the proper way forward.
> 
> This does bring out a question though: one of the use-cases is to switch
> between streaming and non-streaming mode. Currently, the way xsl:merge-
> source is written up, if you are using @use-accumulators, you *must*
> remove the whole attribute if you switch to streaming. However, this is
> (unfortunately) the same with the attribute @for-each-stream, which forces
> the @streamable attribute to take the value "yes". I don't see an easy way to
> align this with the new xsl:source-document, except for use-accumulators:
> allow it to be empty (or add #none as an allowed token) so that static
> expressions can be used in static AVTs.
> 
> This would then support the use case described in the issue about xsl:source-
> document. If we don't make that change, the @use-accumulators limitation
> also limits the usability of the change we are making.
> 
> Alternatively, we can say for both xsl:merge-source and xsl:source-
> document that @use-accumulators is ignored (and suggest that processors
> issue a warning). But this is not ideal.
> 
> Cheers,
> Abel
> 
> > -----Original Message-----
> > From: Michael Kay [mailto:mike@saxonica.com]
> > Sent: Thursday, August 25, 2016 9:16 PM
> > To: XSL Working Group
> > Subject: xsl:source-document/@use-accumulators
> >
> > We have to make a decision on what use-accumulators should do on
> > xsl:source-document when streamable="no".
> >
> > I'm inclined to say that for orthogonality, it means the same as when
> > streamable="yes" - for a document read using xsl:source-document,
> > accumulators are applicable only if listed in use-accumulators.
> >
> > But there are edge cases, e.g. if the same document is read both using
> > doc() and also using xsl:source-document.
> >
> > Michael Kay
> > Saxonica

Received on Friday, 2 September 2016 16:49:19 UTC