Project

Profile

Help

Feature #6216

closed

base-uri() value empty for documents async-loaded with ixsl:schedule-action/@http-request

Added by Martynas Jusevicius about 1 year ago. Updated about 1 year ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
IXSL extensions
Sprint/Milestone:
-
Start date:
2023-10-08
Due date:
% Done:

100%

Estimated time:
Applies to JS Branch:
2, Trunk
Fix Committed on JS Branch:
2, Trunk
Fixed in JS Release:
SEF Generated with:
Platforms:
Company:
-
Contact person:
-
Additional contact persons:
-

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.

Actions #1

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()?

Actions #2

Updated by Martynas Jusevicius about 1 year ago

Not completely related, but base-uri(ixsl:page()) does not return a URI either.

Actions #3

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).

Actions #4

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.

Actions #5

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>
Actions #6

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).

Actions #7

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+)

Actions #8

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?

Actions #9

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.

Actions #10

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()).

Actions #11

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?

Actions #12

Updated by Norm Tovey-Walsh about 1 year ago

Yep, that's persuasive to me.

Actions #13

Updated by Norm Tovey-Walsh about 1 year ago

Fix updated on saxonjs2 branch to remove the fragment identifier.

Actions #14

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.

Actions #15

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.

Actions #16

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