Saxon » SaxonJS

Could you tell us what SaxonJS.transform() call you are using?

This is a snippet of the code:

window.SaxonJS.transform(

{

stylesheetLocation: sef,

initialTemplate: formulaCall.id,

destination: "application",

sourceLocation: `data:text/xml,$

{ window.encodeURIComponent(buildInputXML( getFactValueFnOverride || getFactValueFn, // Allow fn override at call time. getCellInfoFn, formulaCall, unitResolver) ) }

`

},

Hope this helps..

Yes, that is helpful. We must admit we have not tested the use of data URIs for the source location. The Wikipedia page (https://en.wikipedia.org/wiki/Data_URI_scheme) warns that "As of 2015, data URIs are fully supported by most major browsers, and partially supported in Internet Explorer and Microsoft Edge." so this could be a problem specific to IE & Edge which is out of our control. Have you tested your example on other browsers?

It is still hard to tell what it is you are trying to supply as the source. Perhaps you would be better using sourceNode or sourceText rather than sourceLocation (see http://www.saxonica.com/saxon-js/documentation/index.html#!api/transform)?

Thanks for the feedback. Other browser work fine.

We'll refactor the code to use the sourceText.

Hello Debbie (and others),

We've switched our codebase to use the sourceText interface, in stead of the sourceLocation interface. And although this did improve the performance somewhat (I'd say around 70% in our workload - which is a-typical), the exact same error message popped up in IE11 and Chrome. So we have been forced to re-open the bug in our tracking software (JIRA), so this issue is still ongoing and i've re-opened this bug as well.

I'm open, and very reachable, for suggestions as we've run out ;-)

Jan Paul

Are you now trying to supply the SEF as a data URI? Or has something gone wrong with the upload here? When I open the attached test.sef file it begins "data:text/xml..." Please could you upload it again, after first saving it explicitly as an .xml file?

If the XML you are supplying as source actually is a saved file like this, then you really should be able to use the sourceLocation interface after all. You should supply a string with the relative path to the source from the HTML page (e.g. sourceLocation: "xsl/test.sef").

Hi Debbie,

We are seeing that using sourceText gives us much more performance in browser that do work (which is everything except Microsoft browser) so we are going with sourceText anyway. Also, you advised us to use sourceText in the first place since using sourceLocation didn't work in IE/Edge. So neither sourceLocation nor sourceText works. Something else must be going on. Maybe this error message, from an IE11 console, gives you more information?

Transform options supplied: stylesheetLocation, initialTemplate, destination, sourceText,

Unhandled promise rejection Error: Access is denied.

"Unhandled promise rejection"

{

  [functions]: ,

  __proto__: { },

  description: "Access is denied.

",

  message: "Access is denied.

",

  name: "Error",

  number: -2147024891,

  stack: "Error: Access is denied.

at a.asyncGet (https://abcportaal/SaxonJS.min.js:1:11059)

at a.asyncGetXml (https://abcportaal/SaxonJS.min.js:1:11311)

at a.asyncGetMultipleXml (https://abcportaal/SaxonJS.min.js:1:11516)

at transform (https://abcportaal/SaxonJS.min.js:1:5328)

It's good to see the full IE error message, but I'm afraid it does not really tell me much more. I would still like to be able to actually reproduce the problem myself. Can you tell me again exactly what SaxonJS.transform() call you are now using? And attach the test SEF as an XML file (or even the original test XSLT stylesheet and I will generate the SEF myself). Thanks.

Debbie,

We're doing this:

 window.SaxonJS.transform(
            {
              stylesheetLocation: sef,
              initialTemplate: formulaCall.id,
              destination: "application",
              sourceText: inputXml,
            },
            transformResult => {
              resolve(resultParser(transformResult.textContent));
            });

Where the sef is the test.sef I sent you, and the inputXml the test.xml file.

The test.sef file is base64 encoded, you can easily decode it yourself. The SaxonJS code does this for you.

Hi Debbie,

To assist you in isolating the problem, I've made a sample project and uploaded it to my GitHub. I called it "saxonable" since I didn't have inspiration for another name.

This is the minimum viable set to have the error reproduced in a browser. Documentation is in the README of the github project.

https://github.com/janpaul/saxonable

Feel free to clone and make changes, I'm happy to handle pull requests!

Ok thanks. I had made some progress to make a sample HTML page to run the test SEF and XML, but seeing exactly what you are doing is better.

Is there a particular reason that you are using a base64 encoded version of the SEF? I think this is where problems are arising. You are supplying the full string containing this base64 encoded SEF as the stylesheetLocation value in the SaxonJS.transform call. The stylesheetLocation is expected to be a string containing a relative path to the SEF (XML file). Somewhat surprisingly, what you are supplying does work for some browsers - which treat this string as a data URI, and the XMLHttpRequest does actually return the XML as the responseText. But, as previously noted data URIs do not work on IE/Edge.

If you can use an actual XML file instead (say testSEF.xml in the data folder), then in your SaxonJS.transform call you should be able to replace the option stylesheetLocation:sef with stylesheetLocation:"data/testSEF.xml". Then you should not need to do any of the external retrieval of the SEF which you are currently doing, in the doSomeSaxonJS function in app.js.

(Note to self: I would also like to look into the performance difference observed for sourceText versus sourceLocation, since supplying the sourceLocation seems simpler to me, but have not done this yet.)

Hi Debbie,

I hear what you're saying. But our application doesn't work that way. The SEF that we are using is not a file in the filesystem that we can access, it's embedded in another file (a JSON, actually) that we supply to SaxonJS through the location mechanism. Agreed, this works in Chrome/Firefox/Safari. I'm not so sure about the "suprisingly" that you used, what we do should be completely valid in a modern browser. So I would say that "somewhat suprisingly it does NOT work on IE and Edge" ;-)

Performance-wise, I do believe that sourceText should be faster than using sourceLocation, since in the first case we simply inject a string into SaxonJS, whereas in the other case a file has to be read from the filesystem. Aside from other processing that you may do.

The sample repository I built for you is as close to our specific usecase as possible.