Project

Profile

Help

Bug #3309

closed

Configuration options for streaming

Added by Michael Kay about 7 years ago. Updated almost 7 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Streaming
Sprint/Milestone:
-
Start date:
2017-06-24
Due date:
% Done:

0%

Estimated time:
Legacy ID:
Applies to branch:
Fix Committed on Branch:
Fixed in Maintenance Release:
Platforms:

Description

See also https://saxonica.plan.io/boards/3/topics/6829?pn=1&r=6831#message-6831

Several interconnected issues with facilities for configuring how streaming behaves, some probably bugs, some probably documentation errors.

(1) This page: http://www.saxonica.com/documentation/index.html#!sourcedocs/streaming/configuration-streaming mentions streamability="extended" but this option is no longer supported.

(2) It's not really clear in the documentation how the two options STREAMABILITY and STREAMING_FALLBACK are supposed to interact. I think it's supposed to work like this:

(A) In a licensed Saxon-EE configuration:

(a) construct is declared streamable

STREAMABILITY=on: check that the construct is actually streamable. If so, use streaming, if not, then (i) if STREAMING_FALLBACK = on, use a non-streaming implementation. If STREAMING_FALLBACK = off, report a static error (typically XTSE3430)

STREAMABILITY=off: behave as in a Saxon-HE configuration

(B) In a Saxon-HE (or PE or unlicensed EE) configuration:

STREAMABILITY is always OFF and cannot be set ON. STREAMING_FALLBACK is always ON.

(3) the software isn't actually doing the above, at least not systematically for all cases

(4) there aren't many tests of these options, certainly not in combination

Actions #1

Updated by Michael Kay about 7 years ago

(5) Further, the documentation at http://www.saxonica.com/documentation/index.html#!sourcedocs/streaming/configuration-streaming fails to mention the new STRICT_STREAMABILITY option. This option causes an additional check for streamability against the W3C rules to take place, prior to any expression optimization, thus enabling a more precise analysis of whether constructs are streamable according to the W3C rules. Again, it would be helpful to explain how this interacts with the other options.

Actions #2

Updated by Michael Kay about 7 years ago

I have produced a patch for all instructions that have a streamable=yes|no attribute, these now invoke common code which:

(a) strips whitespace and checks that the attribute is a valid boolean value

(b) issues a warning if the value is "yes" and EET is not licensed; and then treats the value as "no"

(c) issues a warning if the value is "yes" and FeatureKeys.STREAMABILITY is off; and then treats the value as "no".

Similar logic is followed for xsl:function/@streamability if the value is other than "unclassified".

Actions #3

Updated by Michael Kay about 7 years ago

  • Status changed from New to In Progress

I have added more checks that Enterprise XSLT is licensed on streaming paths - this is designed to give an early indication of what is wrong rather than allowing the code to crash at run-time.

Actions #4

Updated by Michael Kay almost 7 years ago

  • Status changed from In Progress to Resolved

I've reviewed this and I think it can now be closed as resolved. The necessary code changes and documentation changes have all been made.

Please register to edit this issue

Also available in: Atom PDF