Bug #4576

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

Added by Michael Kay over 1 year ago. Updated about 1 year ago.

Start date:
Due date:
% Done:


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


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.


#1 Updated by Michael Kay about 1 year 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.

#2 Updated by O'Neil Delpratt about 1 year ago

  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 10.2 added

Bug fix applied in the Saxon 10.2 maintenance release.

#3 Updated by O'Neil Delpratt about 1 year ago

  • Status changed from Resolved to Closed

Please register to edit this issue

Also available in: Atom PDF