Project

Profile

Help

Bug #4576

Document identity when doc() or document() selects the initial source document

Added by Michael Kay about 1 month ago. Updated 12 days ago.

Status:
Resolved
Priority:
Low
Assignee:
Category:
Internals
Sprint/Milestone:
-
Start date:
2020-06-05
Due date:
% Done:

0%

Estimated time:
Legacy ID:
Applies to branch:
10, 9.9
Fix Committed on Branch:
10
Fixed in Maintenance Release:

Description

When doc() is called specifying the same URI as the initial source document, it doesn't find the document in the pool and therefore fetches a new document with different node identity. Apparently this changed in 9.9: previously the initial source document was placed in the pool.

Added XSLT3 test case document-2011, but it allows either outcome because the spec isn't prescriptive on this.

Need to watch out for complications involving strip-space options, accumulators, etc, where the options for a single document can vary from one package to another.

History

#1 Updated by Michael Kay 12 days ago

  • Status changed from New to Resolved
  • Applies to branch 10, 9.9 added
  • Fix Committed on Branch 10 added

I think it's actually putting the document in the pool on some activation paths (Controller.buildSourceTree()) and not others (Controller.setGlobalContextItem()). I've changed Controller.setGlobalContextItem() so if a document node is supplied, and it has a known systemId, then it's placed in the pool.

I found some other odd code in Controller.setGlobalContextItem() -- it was checking any previously-supplied global context node to check it was in the right configuration, but not checking the newly supplied global context node. I've fixed that.

I'm making these changes only on the 10.0 branch, in the interests of stability.

Please register to edit this issue

Also available in: Atom PDF