- From: <bugzilla@jessica.w3.org>
- Date: Tue, 18 Oct 2016 09:31:08 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29939 --- Comment #1 from Michael Kay <mike@saxonica.com> --- 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. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Tuesday, 18 October 2016 09:31:18 UTC