Saxon

Testing now.

That worked in the config file, however I will eventually need the licenseFileLocation to be set programmatically.

Also, the following exception was thrown again downstream: "URI has an authority component" when reaching the line below:

var transformer = _xsltCompiler.Compile(new Uri(stylesheetPath)).Load();

The stylesheetpath uri has been working for months while on SaxonHE, now that we've upgraded to SaxonPE these issues have surfaced. So I don't think the issue is the stylesheet URI as much as it is on the following XSLT calls (but I'm no expert): e.g. file:base-dir, file:parent, and file:list see snippet below.

<xsl:function name="pn:find-image-filepath">
        <xsl:param name="filename"/>

        <xsl:variable name="file-path"
                      select="file:list(file:parent(file:base-dir()), true(), concat($filename, '*'))[1]"/>

        <xsl:choose>
            <xsl:when test="$file-path">
              <xsl:value-of select="file:path-to-uri(concat(file:parent(file:base-dir()), $file-path)))"/>
            </xsl:when>
            <xsl:otherwise>
                <xsl:message terminate="no">Could not find image file "<xsl:value-of select="$filename"/>"
                </xsl:message>
            </xsl:otherwise>
        </xsl:choose>
    </xsl:function>

Is there a way I can set a setting to tell Saxon to ignore particular parsing issues? e.g warnings vs. fatal errors

The issue is going to surface if the stylesheet does anything that makes use of the static base URI, and there are quite a few things that can make use of the static base URI; this is just one example. It would be hard to change all those places to tolerate an invalid URI. For example, relative URIs appearing in xsl:include, xsl:import, or calls on doc() and document() would fail in similar ways.

I'm thinking that since new Uri() doesn't guarantee that the value is a usable URI, we should put some extra validation in at the point of the Compile call to make sure that it's usable, and try and reject it with a decent error message if not.

Note: I think we're now discussing the same issue as in bug #4280, so I suggest we close this one to avoid confusion.

Michael,

I'm not sure how to close this ticket.

Michael,

Licensing should NOT be an issue for us as we purchased a redistributable license.