Saxon

Well, it looks like we're invoking relative URI resolution even though the href is absolute, and it's failing because the base URI isn't heirarchic. Sounds off-hand like something that's probably conformant but a bit unfriendly.

Thanks, I have now identified the stylesheet code as doing <xsl:sequence select="resolve-uri($chunk-output-base-uri, base-uri(root($node)/*))"/>, will need to check further where the variables are set and try to understand what resolve-uri is supposed to do.

The spec has the paragraph

A dynamic error is raised [err:FORG0002] if $base is not a valid IRI according to the rules of RFC3987, extended with an implementation-defined subset of the extensions permitted in LEIRI, or if it is not a suitable IRI to use as input to the chosen resolution algorithm (for example, if it is a relative IRI reference, if it is a non-hierarchic URI, or if it contains a fragment identifier).

Hmm, seems some Docbook oddity, it looks like it does e.g. resolve-uri('', 'urn:from-string') , based on

<xsl:param name="chunk-output-base-uri" as="xs:string">
  <xsl:choose>
    <xsl:when test="not($v:chunk)">
      <!-- it doesn't actually matter -->
      <xsl:sequence select="''"/>
    </xsl:when>
    <xsl:when use-when="function-available('ext:cwd')"
              test="true()">
      <xsl:message select="'Default output base uri:',
                           resolve-uri(ext:cwd(), static-base-uri())"/>
      <xsl:sequence select="resolve-uri(ext:cwd(), static-base-uri())"/>
    </xsl:when>
    <xsl:otherwise>
      <xsl:message terminate="yes"
                   select="'You must specify the $chunk-output-base-uri'"/>
    </xsl:otherwise>
  </xsl:choose>
</xsl:param>

I guess most people will not run Docbook through that fiddle, I will see whether I can improve the error message of the fiddle to include the stylesheet module.

And the question is whether that rule takes precedence over the rule

If $relative is an absolute IRI (as defined above), then it is returned unchanged.

Section 1.4 says:

The next section in the proforma defines the semantics of the function as a set of rules. The order in which the rules appear is significant; they are to be applied in the order in which they are written. Error conditions, however, are generally listed in a separate section that follows the main rules, and take precedence over non-error rules except where otherwise stated.

which suggests that the error rule takes precedence here.

However 1.4 also says

The principles outlined in Section 2.3.4 Errors and Optimization XP31 apply by default: to paraphrase, if the result of the function can be determined without evaluating all its arguments, then it is not necessary to evaluate the remaining arguments merely in order to determine whether any error conditions apply.

which suggests that if the href argument is absolute, we can return a result without evaluating the base argument. So I think we have discretion.

Hmm, seems some Docbook oddity, it looks like it does e.g.
resolve-uri('', 'urn:from-string') , based on

I’ll see if I can improve the DocBook stylesheets. Getting the output
URIs correct is a bit fiddly (don’t even get me started about getting
the “input URIs” of images correct relative to the “output URI” of the
chunk in which they appear!).

Be seeing you,
norm

--
Norm Tovey-Walsh
Saxonica

I added test case fn-resolve-uri-33 which does

resolve-uri("http://www.example.com/books.xml", "urn:doi:234567")

and allowing both "http://www.example.com/books.xml" and FORG0002 as allowed outcomes.

SaxonJ 11.3 is returning "http://www.example.com/books.xml". It tests whether the URI is absolute before looking at $base.

This is an explicit call on fn:resolve-uri(), and it's possible that URI resolution for xsl:include (say) is taking a different path.

UseWhenFilter.processIncludeImport() passes both href and base to DocumentFn.computeDocumentKey(), which calls ResolveURI.makeAbsolute(href, baseURI). I'll put together a test for this path.

I found that

<xsl:import href="file:///Users/mike/Desktop/temp/test-fa.xsl" xml:base="urn:doi:1234"/>

works fine, so I think we're consistent. The error complaining that the base URI is non-hierarchic should only occur if $relative is not an absolute URI.

Yes, Mike, thanks for your effort, it seems, as I commented somewhere, that the Docbook stylesheet (as at some point it does not care about a real base output uri as it is not "chunking") assigns the empty string '' as the base output uri and does resolve-uri('', 'urn:from-string') in a code path that then correctly causes the error by Saxon. I had never run into that message so I couldn't quite figure what was causing it or what is was related to. But Saxon is not at fault here.

I've updated the DocBook xslTNG stylesheets so that they won't raise this exception when chunking isn't in use. Clearly, I never tested the stylesheets with an input document that had a non-hierarchical URI.