Project

Profile

Help

Bug #3098

Supplied value "..." is not a valid xs:base64

Added by Pieter Masereeuw over 1 year ago. Updated about 1 year ago.

Status:
Closed
Priority:
Low
Sprint/Milestone:
-
Start date:
2017-01-09
Due date:
% Done:

100%

Applies to JS Branch:
0.9, Trunk
Fix Committed on JS Branch:
1.0
Fixed in JS Release:
SEF Generated with:
Company:
Pieter Masereeuw
Contact person:
Pieter Masereeuw
Additional contact persons:
-

Description

I hope that I am right that I have found a bug in the runtime of Saxon-JS-beta-0.9.1.1. I have an xsl:choose, the first test compares a string parameter with a string literal. Although the parameter can hardly be anything else but an xs:string (also by the as= clause of its definition), I get the error "Supplied value "..." is not a valid xs:base64" in the javascript console of Firefox and Chrome. If I cast the parameter by wrapping it in xs:string(), the error remains. But if I concat an empty string before doing the compare, all goes well, even when the parameter value matches another xsl:when inside the same xsl:choose-stanza.

Maybe useful to remark that part of its life time, the parameter is a tunnel parameter.

You can watch the working version at http://www.masereeuw.nl/tangram. I'll be happy to supply source code if that helps.

Here is an abbridged snipped of my code:

@

    <xsl:param name="next-figure" as="xs:string" required="yes"/>


    <xsl:choose>

        <!-- Intended line was:


            <xsl:when test="$next-figure eq 'transparant-tangram'">


            but for some reason this fails with an error in the Javascript console:

            XError: Supplied value "sitting-cat" is not a valid xs:base64 at file:/home/pieter/saxonjs-experimenten/tangram/tangram4saxonjs.xslt#227


            When we change the test as shown (concatening an empty string, then compare), all goes well, even if the other comparable tests are

            left as they are.

        -->

        <xsl:when test="concat($next-figure, '') eq 'transparant-tangram'">

            <xsl:call-template name="do-transparant-tangram">

                <xsl:with-param name="transforms" select="$tangram-transforms"/>

            </xsl:call-template>

        </xsl:when>


        <xsl:when test="$next-figure eq 'blue-tangram'">

            <xsl:call-template name="do-blue-tangram">

                <xsl:with-param name="transforms" select="$tangram-transforms"/>

            </xsl:call-template>

        </xsl:when>

<!-- ... -->

        <xsl:otherwise>

            <xsl:message>Don't know how to deal with figure "<xsl:value-of select="$next-figure"/>".</xsl:message>

        </xsl:otherwise>

    </xsl:choose>

</xsl:template>@

History

#1 Updated by Debbie Lockett over 1 year ago

  • Status changed from New to In Progress
  • Assignee set to Debbie Lockett
  • Found in version changed from Saxon-JS-beta-0.9.1.1.zip to 0.9.1

Hi Pieter,

Thanks for letting us know about the bug. I have managed to obtain the source code via the link to the demo that you provided. I shall investigate.

I like the demo! We are always interested in hearing from people who are using Saxon-JS. Any other feedback you have would be most welcome.

Debbie

#2 Updated by Pieter Masereeuw over 1 year ago

  • Company set to Pieter Masereeuw
  • Contact person set to Pieter Masereeuw

Hi Debbie,

I am glad that I also copied the source files to the site then. If I

can be of any other help, please let me know. I certainly like the

Saxon-JS product; I think it will offer a good replacement for many web

applications whose source code is now overly complex.

Best,

Pieter

On Mon, 2017-01-09 at 13:29 +0100, Saxonica Developer Communi;ty wrote:

#3 Updated by Debbie Lockett over 1 year ago

  • Status changed from In Progress to Resolved
  • Applies to branch 9.7 added

The bug arises from a cast to base64Binary when processing a 'switch' expression in Expr.js.

To fix the bug, we have suppressed the choose -> switch optimisation for target="JS" on the 9.7 branch (this had previously already been suppressed on the 9.8 branch, on 2016-11-11). So when exporting using Saxon-EE 9.7.0.15 or later, an SEF will not contain any 'switch' expressions.

The next Saxon-JS release will no longer process 'switch' expressions. Now if Saxon-JS encounters a 'switch' expression in an SEF, an error is raised which tells the user to regenerate the SEF with Saxon-EE 9.7.0.15 or later.

#4 Updated by Michael Kay over 1 year ago

A little bit of background here to explain what is going on...

When you use a choose expression like this:

xsl:choose

.../xsl:when

.../xsl:when

.../xsl:when

...

and the conditions are all mutually exclusive, then Saxon-EE tries to optimize this (into a so-called "switch" expression) by doing a hash-table lookup on the collation key of $a. Collation keys are base64Binary values. Because reproducing collation keys and hash codes across Java and Javascript isn't easy, we decided the simplest solution was to suppress this optimization when generating code for Saxon-JS, at least for the time being.

#5 Updated by Debbie Lockett over 1 year ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in version set to 1.0.0

Bug fix applied in the Saxon-JS 1.0.0 release.

#6 Updated by Community Admin about 1 year ago

  • Fixed in JS Release set to Saxon-JS 1.0.0
  • Applies to JS Branch 0.9 added
  • Fix Committed on JS Branch 1.0 added

#7 Updated by Community Admin about 1 year ago

  • Applies to JS Branch Trunk added

Please register to edit this issue

Also available in: Atom PDF Tracking page