Project

Profile

Help

Bug #4745

Testing for "the same" schema location is not sensitive to relative path

Added by Norm Tovey-Walsh 12 months ago. Updated 11 months ago.

Status:
Closed
Priority:
Low
Category:
-
Sprint/Milestone:
-
Start date:
2020-09-22
Due date:
% Done:

100%

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

Description

Determining if two schema components are "the same" (and thus not a redeclaration of a component) can depend on determining whether or not the schema locations from which those components were loaded are "the same". If two components are loaded from the same URI, they are assumed to be the same component.

However, it is possible for the relative locations to have URIs that appear to be different: file:/path/to/schema.xsd in one case and file:/path/to/subdirectory/../schema.xsd in the other. (This case arises in the junit Validator tests, for example).

Differences in relative paths should be normalized when comparing locations.

History

#1 Updated by Michael Kay 12 months ago

Makes sense.

Note there's a static method DocumentKey.normalizeURI() used for a similar purpose - detecting when doc() uses the URI of something already in cache. it seems to handle some ignorable differences between equivalent URIs, but not this one. I'd suggest improving that method and using it.

#2 Updated by Michael Kay 12 months ago

Note also, for Element declarations the code moved away from comparing components by source location, and instead does a value-based comparison (ElementDecl.isSameDeclaration()). But for other kinds of component, e.g.attribute declarations and types (UserDefinedType.isSameType()) it's still location-based. In general doing a value-based comparison is hard, because we're in the middle of a network of related components, not just a hierarchy. I think Element Declarations were special cased to make xs:override work, but I don't recall the details.

#3 Updated by Norm Tovey-Walsh 12 months ago

  • Status changed from New to In Progress

#5 Updated by Norm Tovey-Walsh 12 months ago

  • Fix Committed on Branch 10, trunk added

Fixed in 10 and trunk.

#6 Updated by Norm Tovey-Walsh 12 months ago

  • Fix Committed on Branch 9.9 added

And fixed in 9.9

#7 Updated by Norm Tovey-Walsh 12 months ago

  • Status changed from In Progress to Resolved

#9 Updated by O'Neil Delpratt 11 months ago

  • Fixed in Maintenance Release 9.9.1.8 added

Bug fix applied on the Saxon 9.9.1.8 maintenance release. Leaving open until applied on the Saxon 10 maintenance release.

#10 Updated by O'Neil Delpratt 11 months ago

Bug fix applied in the Saxon 10.3 maintenance release

#11 Updated by O'Neil Delpratt 11 months ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 10.3 added

Please register to edit this issue

Also available in: Atom PDF