Bug #3130: Source document has a non-absolute base-uri() - SaxonJS - Saxonica Developer Community

Actions

Send by e-mail Copy link

Bug #3130

closed

Source document has a non-absolute base-uri()

Added by John Lumley almost 8 years ago. Updated over 7 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Debbie Lockett

Category:

Sprint/Milestone:

Start date:

2017-02-15

Due date:

% Done:

100%

Estimated time:

Applies to JS Branch:

1.0

Fix Committed on JS Branch:

1.0

Fixed in JS Release:

Saxon-JS 1.0.1

SEF Generated with:

Platforms:

Company:

Contact person:

Additional contact persons:

Description

A document loaded via transform()/sourceLocation appears to have a non-absolute base-uri, actually just the value of the sourceLocation option. If a stylesheet attempts to resolve a relative URI from e.g. @href in that document, resolve-@uri(@href,base-uri(.))@ fails as the document doesn't have an absolute URI.

Actions

Copy link

Updated by Debbie Lockett over 7 years ago

Status changed from New to Resolved

The problem was that the _saxonBaseUri property (as used by CoreFn.base-uri) had not been set correctly on the source document node. This should be set within BrowserPlatform.asyncGetXml() when the source document is loaded.

Note that we were actually using two similar properties: _saxonBaseUri and _saxonDocumentUri. The former was used by CoreFn.base-uri, and the latter by CoreFn.document-uri. Sometimes both were being set, and sometimes only one. In some cases this was caught later in the processing (as _saxonDocumentUri was copied to _saxonBaseUri), but not always. This is unnecessarily complicated.

This is now fixed by removing the use of _saxonDocumentUri, and only using _saxonBaseUri instead.

Furthermore, as well as ensuring _saxonBaseUri is set when the source is loaded via the sourceLocation transform option, we now also set it in the case that the source is loaded via the sourceNode transform option and node.baseUri is not null.

Actions

Copy link