I see the problem—in the code below, the document is then transformed, so the
behavior I’m seeing is correct for base-uri() (and maybe correct for
document-uri()?).
The transformed result of the input document should set xml:base to the
original URI in order for base-uri() to then return a useful value.
Cheers,
E.
--
Eliot Kimber
http://contrext.com
From: "Eliot Kimber ekimber(_at_)contrext(_dot_)com"
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com>
Reply-To: <xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com>
Date: Wednesday, August 18, 2021 at 11:56 AM
To: <xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com>
Subject: Re: [xsl] In XSLT context, base-uri() and document-uri() return
different values
The document from which the element I’m applying base-uri() to is constructed
thusly:
<xsl:variable name="input.map" as="document-node()?">
<xsl:apply-templates select="document($input.map.url)"
mode="normalize-map"/>
</xsl:variable>
And then the variable with the element is constructed like so:
<xsl:variable name="current-topicrefs" select="$input.map//*[contains(@class,
' map/topicref ')][dita-ot:get-path($PATH2PROJ, .) = $current-file]"
as="element()*"/>
<xsl:variable name="current-topicref" select="$current-topicrefs[1]"
as="element()?"/>
Given that document-uri(root($current-topicref)) returns the correct (or at
least expected) answer, it suggests that something is off with base-uri().
Cheers,
E.
--
Eliot Kimber
http://contrext.com
From: "Michael Kay mike(_at_)saxonica(_dot_)com"
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com>
Reply-To: <xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com>
Date: Wednesday, August 18, 2021 at 10:52 AM
To: xsl-list <xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com>
Subject: Re: [xsl] In XSLT context, base-uri() and document-uri() return
different values
We've had to make changes to document-uri() because we were setting it in cases
where we couldn't guarantee that two different documents never have the same
document-uri(), which is an implicit requirement of the spec. For example
copy-of should retain the base URI but drop the document URI.
I'm not aware of any corresponding changes to base URI, but it could be
collateral damage. Neither concept maps particularly well to the Java concept
of System ID.
How is this document being created?
Michael Kay
Saxonica
On 18 Aug 2021, at 16:27, Eliot Kimber ekimber(_at_)contrext(_dot_)com
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
In the context of an XSLT 3 transform run by Saxon-HE 9.9.1.7J, I have a
variable that contains an element from a document loaded using the document()
function.
In my code I use base-uri() to get the base URI of the element in order to then
resolve URIs relative to this element. This is in code that’s been around a
long time (nearly 10 years).
In my latest use of this code, I’m seeing that base-uri() for the node reflects
the URI of the transform, not the node, but document-uri() for the element’s
root returns the expected document URI:
[xslt] + [DEBUG] df:resolveTopicRef():
base-uri($context)="file:/Users/eliot.kimber/git/dita-ot/dita-ot-air/plugins/org.dita.html5/xsl/map2html5Impl.xsl"
[xslt] + [DEBUG] df:resolveTopicRef():
document-uri($context)="file:/Users/eliot.kimber/git/temp/aair/air-html/bundle-aair-automated-incident-response.ditamap"
My understanding of base-uri() is that I should get the same values for
base-uri() and document-uri() in this case because there are no explicit
xml:base attributes in the source document.
Why am I seeing this anomalous result from base-uri()? I didn’t see anything in
the XSLT 3 spec or in the XPath spec that would suggest this behavior (looking
for mentions of “base-uri”).
Thanks,
Eliot
--
Eliot Kimber
http://contrext.com
XSL-List info and archive
EasyUnsubscribe (by email)
XSL-List info and archive
EasyUnsubscribe (by email)
XSL-List info and archive
EasyUnsubscribe (by email)
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--