Bug #3098
closedSupplied value "..." is not a valid xs:base64
100%
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:template name="do-next-figure">
<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>@
Updated by Debbie Lockett almost 8 years 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
Updated by Pieter Masereeuw almost 8 years 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:
Updated by Debbie Lockett almost 8 years 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.
Updated by Michael Kay almost 8 years ago
A little bit of background here to explain what is going on...
When you use a choose expression like this:
<xsl:when test="$a = 'a'>...</xsl:when>
<xsl:when test="$a = 'b'>...</xsl:when>
<xsl:when test="$a = 'c'>...</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.
Updated by Debbie Lockett almost 8 years 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.
Updated by Community Admin over 7 years 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
Please register to edit this issue
Also available in: Atom PDF Tracking page