Bug #4745: Testing for "the same" schema location is not sensitive to relative path - Saxon - Saxonica Developer Community

Actions

Send by e-mail Copy link

Bug #4745

closed

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

Added by Norm Tovey-Walsh over 3 years ago. Updated over 3 years ago.

Status:

Closed

Priority:

Low

Assignee:

Norm Tovey-Walsh

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:

9.9.1.8, 10.3

Platforms:

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.

Actions

Copy link

Updated by Michael Kay over 3 years 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.

Actions

Copy link

Updated by Michael Kay over 3 years 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.

Actions

Copy link