Bug #3130
closed
Source document has a non-absolute base-uri()
Fix Committed on JS Branch:
1.0
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.
- 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.
- Applies to branch deleted (
9.7, 9.8)
- Applies to JS Branch 1.0 added
- Fix Committed on JS Branch 1.0 added
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in JS Release set to Saxon-JS 1.0.1
Bug fix applied in Saxon-JS 1.0.1 maintenance release.
Please register to edit this issue
Also available in: Atom
PDF
Tracking page