This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I'm rather confused by the stylesheet-base-uri option. (CASE 1) In combination with "stylesheet-text", it makes sense. Since the stylesheet-text is a string, there is no associated base URI. The text can be parsed as if by a call to parse-xml with a static context base URI of stylesheet-base-uri. (CASE 2) In combination with "stylesheet-node" it is confusing. Take as example fn-transform-19. <test-case name="fn-transform-19"> <description>Transform using options stylesheet-node and stylesheet-base-uri</description> <created by="Debbie Lockett" on="2015-03-11"/> <dependency type="spec" value="XQ31+"/> <dependency type="feature" value="fn-transform-XSLT" satisfied="true" /> <test><![CDATA[ declare variable $xsl as xs:string :="<xsl:stylesheet version='2.0' xmlns:xsl='http://www.w3.org/1999/XSL/Transform'> <xsl:template name='main'> <x><xsl:value-of select='static-base-uri()'/></x> </xsl:template> </xsl:stylesheet>"; fn:transform(map {"stylesheet-node" : parse-xml($xsl), "initial-template" : QName('','main'), "stylesheet-base-uri": "http://www.example.com"})?output ]]></test> <result> <assert>$result/x = 'http://www.example.com'</assert> </result> </test-case> The static base URI property from the static context of the fn:parse-xml function call is used both as the base URI used by the XML parser to resolve relative entity references within the document, and as the base URI of the document node that is returned. Let's say that's urn:foo. At the <xsl:value-of /> element, the URI will still be urn:foo. Sicne the XPath expression static-base-uri() executes with a static context whose base URI is the base URI of the containing element, the expected result should be urn:foo. The "stylesheet-base-uri" option can't have an effect. (CASE 3) Consider "stylesheet-base-uri" In combination with "stylesheet-location". Suppose the implementation uses the stylesheet-location to load an XDM instance as if by a call to fn:doc. The base URI of the document node of the loaded instance would be that of the stylesheet-location. This is similar to CASE 1 and "stylesheet-base-uri" would have no effect. Suppose instead that the implementation loaded the stylesheet in as if by a call to unparsed-text, followed by parsing as if by a call to parse-xml. This is similar to CASE 2 and "stylesheet-base-uri" would have an effect. I would expect "stylesheet-base-uri" only to apply in combination with "stylesheet-text". It's probably too late in the day, but as an aside, it might have made sense to give fn:parse-xml an optional base-uri argument.
What the spec says is: The static base URI of the principal stylesheet module. Defaults to the value of stylesheet-location or the base URI of stylesheet-node if available; otherwise absent (which may cause failures, for example if an xsl:include or xsl:import is present with a relative URI). If the value is a relative reference, it is resolved against the static base URI of the fn:transform function call. I think there are two cases where it is useful: (a) when the input has no known base URI, e.g. input from raw lexical XML or from a DOM, or when the static base URI of the function call itself is meaningless (which will often be the case if the call is from XPath). (b) when you want more control over the base URI e.g. for resolving relative xsl:include and xsl:import references. XSLT 3.0 says "Static base URI: In a conventional interpreted environment, the static base URI of an expression in the stylesheet is the base URI of the containing element in the stylesheet." and then goes on to list other possibilities. There's a very wide range of operational scenarios possible here including the case for example where the actual stylesheet execution is done remotely. Cross-site scripting rules might impose constraints. So I would expect some variation in the operational semantics - this function is designed on the basis that it has to handle a lot of variability in operational details. I think it would be a mistake to try and reduce the amount of flexibility on offer.
I'm targetting XSLT 2.0 processors, for which the base URI was solely described as follows. "The base URI is the base URI of the containing element. The concept of the base URI of a node is defined in Section 5.2 base-uri Accessor" The full text from XSLT 3.0 says: "Static base URI: In a conventional interpreted environment, the static base URI of an expression in the stylesheet is the base URI of the containing element in the stylesheet. The concept of the base URI of a node is defined in Section 5.2 base-uri Accessor DM30. When stylesheets are executed in an environment where no source code is present (for example, because the code of the stylesheet has been compiled and is distributed as executable object code), it is recommended (subject to operational constraints such as security) that the static base URI used during stylesheet evaluation should be the location from which the stylesheet was loaded for execution (its "deployed location"). This means, for example, that when the docFO30 or document functions are called with a relative URI, the required document is by default located relative to the deployed location of the stylesheet. Whether or not the stylesheet is executed directly from source code, it is possible that no static base URI is available, for example because the code was supplied as an anonymous input stream, or because security policies are set to prevent executable code discovering the location from which it was loaded. If the static base URI is not known, the static-base-uriFO30 function returns an empty sequence, and other operations that depend on the static base URI may fail with a dynamic error." So I see if you are targetting an XSLT 3.0 processor, you could set the static base URI as described in the second paragraph, and that CASE 1 corresponds to "the code was supplied as an anonymous input stream" (where specifying a stylesheet base URI makes sense). Could you clerify whether setting the stylesheet-base-uri option instructs the XSLT processor to ignore the base URI properties of all nodes read from the principal stylesheet module, i.e. including any which are derived from xml:base attributes?
The WG had some sympathy: editor actioned to produce a specific proposal.
I propose replacing the existing text The static base URI of the principal stylesheet module. Defaults to the value of stylesheet-location or the base URI of stylesheet-node if available; otherwise absent (which may cause failures, for example if an xsl:include or xsl:import is present with a relative URI). If the value is a relative reference, it is resolved against the static base URI of the fn:transform function call. by A string intended to be used as the static base URI of the principal stylesheet module. This value must be used if no other static base URI is available. If the supplied stylesheet already has a base URI (which will generally be the case if the stylesheet is supplied using <code>stylesheet-node</code> or <code>stylesheet-location</code>) it is implementation-defined whether this parameter has any effect. If the value is a relative reference, it is resolved against the static base URI of the fn:transform function call.
The proposal was accepted.
The change has been applied to the spec.