Re: XSLT 3.0 streaming vs other big-data technologies

Simply moving to a 64-bit long would allow an InputStream that would take a
million years or so to process, which is infinite enough for most people.

This particular limit is easy to fix. There are others that are harder: 32-bit
limits on the size of sequences and strings are scattered throughout Saxon not
to mention the Java VM itself. One example: a streamable stylesheet can call
position() to get the position of the current node, and position() is a 32-bit
int. Similarly xsl:number uses 32-bit integers. Moving to 64 bits everywhere
would be a significant challenge, not least because of the difficulty of
testing all paths with the large data volumes needed to find the bugs.

Michael Kay
Saxonica

> On 14 Jun 2018, at 06:19, Mukul Gandhi gandhi.mukul@xxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> Hi Mike,
>
> On Wed, Jun 13, 2018 at 1:00 PM, Michael Kay mike@xxxxxxxxxxxx
<mailto:mike@xxxxxxxxxxxx> <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx
<mailto:xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>> wrote:
>
> The Saxon implementation does have some limits that mean the input stream
can't be infinite: most obviously, the nodes are numbered using a 32-bit
integer.
>
> Can't Saxon use java.math.BigInteger instead of the 32-bit integer data
type? (if 32-bit integer constraint is not allowing Saxon to process
theoretically infinite size input stream).
>
>
>
>
> --
> Regards,
> Mukul Gandhi
> XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
> EasyUnsubscribe <-list/293509> (by email <>)