Feature #6216
closedbase-uri() value empty for documents async-loaded with ixsl:schedule-action/@http-request
100%
Description
I made a little test (live link) that shows that base-uri()
returns an empty string for documents loaded using <ixsl:schedule-action>
(unlike for those loaded using document()
).
I don't see why the two shouldn't be aligned. I think the ?href
value used in @http-request
should be returned as the base-uri()
value.
I thought I could work around this by setting the baseURI
property myself, but turns out it's read-only.
Updated by Martynas Jusevicius about 1 year ago
My bad, actually baseURI
already returns the value I'm looking for. But why not base-uri()
?
Updated by Martynas Jusevicius about 1 year ago
Not completely related, but base-uri(ixsl:page())
does not return a URI either.
Updated by Martynas Jusevicius about 1 year ago
Another weird discovery is that in the browser, the baseURI
property is undefined for attribute nodes (though according to MDN it should work on all types of nodes).
Updated by Michael Kay about 1 year ago
When you talk of "the baseURI property for attribute nodes" are you talking about Javascript or about XDM/XPath?
The XPath base-uri() function is defined in the Functions and Operators 3.1 specification, which itself refers to XDM 3.1. This says that base-uri()
applied to an attribute should return the base URI of its parent element if it has one.
Updated by Martynas Jusevicius about 1 year ago
Interesting, I didn't know that. With baseURI
I was referring to Javascript, with base-uri
to XPath.
I am trying to get a consistent behaviour of base-uri()
in server- as well as client-side stylesheets (Saxon-HE and SaxonJS).
Due to this issue I had to create my own client-side function for now, which seems to do the job (with the XDM logic for text and attribute nodes):
<xsl:function name="ldh:base-uri" as="xs:anyURI?">
<xsl:param name="arg" as="node()"/>
<xsl:choose>
<xsl:when test="($arg instance of attribute()) or ($arg instance of text())">
<xsl:sequence select="if (ixsl:contains($arg/.., 'baseURI')) then ac:document-uri(ixsl:get($arg/.., 'baseURI')) else ()"/>
</xsl:when>
<xsl:otherwise>
<xsl:sequence select="if (ixsl:contains($arg, 'baseURI')) then ac:document-uri(ixsl:get($arg, 'baseURI')) else ()"/>
</xsl:otherwise>
</xsl:choose>
</xsl:function>
Updated by Martynas Jusevicius about 1 year ago
ac:document-uri()
in the example simply cuts the fragment ID off of the baseURI
value (since it can contain fragments for some reason).
Updated by Norm Tovey-Walsh about 1 year ago
- Status changed from New to Resolved
- Fix Committed on JS Branch 2 added
Fixed for SaxonJS 2.6+
(Different fix needed for Saxon JS 3+)
Updated by Martynas Jusevicius about 1 year ago
Norm, great to see a quick fix! Does base-uri()
strip the fragment ID? And does base-uri(ixsl:page())
now work as well?
Updated by Norm Tovey-Walsh about 1 year ago
For consistency with JavaScript and the baseURI
property, I've left the fragment identifier in place.
The fix for this bug doesn't change the behavior of base-uri(ixsl:page())
. I'm not sure fixing that is in-scope for 2.6 given that we'd like to get it out asap.
Updated by Martynas Jusevicius about 1 year ago
I'd rather it be consistent with Saxon-HE and the XDM/XPath specs than Javascript :)
OK I'll open another issue re. base-uri(ixsl:page())
.
Updated by Martynas Jusevicius about 1 year ago
Norm, can we please strip the fragment identifier from base-uri()
? RFC3986 5.1 states:
A base URI must conform to the
<absolute-URI>
syntax rule (Section 4.3). If the base URI is obtained from a URI reference, then that reference must be converted to absolute form and stripped of any fragment component prior to its use as a base URI.
If base-uri()
includes a fragment identifier, then resolve-uri('foo', base-uri())
would/should throw an error. Then it's not much of a base URI, is it?
Updated by Norm Tovey-Walsh about 1 year ago
Fix updated on saxonjs2 branch to remove the fragment identifier.
Updated by Debbie Lockett about 1 year ago
- Category set to IXSL extensions
- Applies to JS Branch Trunk added
- Fix Committed on JS Branch Trunk added
Fix committed on main branch: to add the required _saxonBaseUri
and _saxonDocUri
properties to response body XML documents in Fetch.httpRequestPromise
.
Test ported to main branch.
Updated by Debbie Lockett about 1 year ago
- Subject changed from base-uri() value empty for async-loaded documents to base-uri() value empty for documents async-loaded with ixsl:schedule-action/@http-request
Note that for documents async-loaded using ixsl:schedule-action/@document
, the _saxonBaseUri
and _saxonDocUri
properties are added at the point that the document is actually accessed from the response cache with a call of doc()
or document()
(since this is when the response string is actually parsed to get the XML document). Documents loaded using ixsl:schedule-action/@http-request
are not added to the document pool or accessed from XSLT in the same way; but the _saxonBaseUri
and _saxonDocUri
properties should be added when parsing to an XML document (this is what the code fixes do).
Also note that we use our own _saxonBaseUri
property because the results from the JavaScript baseURI
property are not always reliable for external resources.
Updated by Debbie Lockett about 1 year ago
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in JS Release set to SaxonJS 2.6
Bug fix applied in the SaxonJS 2.6 maintenance release.
Please register to edit this issue
Also available in: Atom PDF Tracking page