Project

Profile

Help

Bug #6050

closed

Schema fails to compile under Saxon 11 - an imported type is held as an unresolved SimpleTypeDefinition

Added by Michael Kay about 1 year ago. Updated 7 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Schema-Aware processing
Sprint/Milestone:
-
Start date:
2023-05-25
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
11, 12, trunk
Fix Committed on Branch:
11, 12, trunk
Fixed in Maintenance Release:
Platforms:
.NET, Java

Description

Email from client:

We faced this problem which we think it may be a bug in saxon. we first load person.xsd then simple.xsd then we evaluate the common.xq. and get this exception:

Exception in thread "main" java.lang.ClassCastException: class com.saxonica.ee.schema.sdoc.SimpleTypeDefinition cannot be cast to class net.sf.saxon.type.AtomicType (com.saxonica.ee.schema.sdoc.SimpleTypeDefinition and net.sf.saxon.type.AtomicType are in unnamed module of loader 'app') as work around i did this but my team want to have feedback from saxon team:

Iterable<SchemaType> allTypes = config.getSuperSchema().getAllTypes();
allTypes.forEach(type -> {
if(type instanceof SimpleTypeDefinition t){
UserSimpleType workingType = t.getWorkingType();
workingType.setRedefinitionLevel(1);
config.getSuperSchema().addType(workingType);
}
});

it looks like the redefinitionlevel make difference in the new version.

Actions #2

Updated by Michael Kay about 1 year ago

  • Status changed from New to In Progress

I have reproduced the problem.

Actions #3

Updated by Michael Kay about 1 year ago

This problem used to arise quite a lot, but I haven't seen it for several years.

The basic problem is that when we first encounter a simple type definition, we create a SimpleTypeDefinition object to represent it, and later on, when we have information about its base type, we try to replace the SimpleTypeDefinition with an AtomcType, ListType, or UnionType depending on its variety. But Java provides no easy way of ensuring that all references to the SimpleTypeDefinition are updated to point to its replacement. This means that any code looking for a simple type needs to be prepared to follow an indirection. This query is taking the code down a path where for some reason the indirection isn't being handled.

Actions #4

Updated by Michael Kay about 1 year ago

The following fix seems to work; in PreparedSchema.getType(), add the logic:

       if (type instanceof SimpleTypeDefinition) {
            SimpleType workingType = ((SimpleTypeDefinition) type).getWorkingType();
            if (workingType != null) {
                type = workingType;
            }
        }
Actions #5

Updated by Michael Kay about 1 year ago

Congratulations on your detective work, by the way. You've identified the essence of the problem, which can't have been easy.

My above fix really just detects the problem and fixes it at the time a type is retrieved. Ideally, it should be fixed earlier at the time the schema is validated and added to the configuration.

The problem here is that an imported schema is actually added to the Configuration without being fully validated. This is unfortunate, and is one of the causes of the multi-threading problem identified in bug #5978. The problem is that when we do an import, the referenced schema is not necessarily complete, for example it may contain a simple type whose base type (and therefore variety) is still unknown.

Your approach is rational: why not update the type table in the PreparedSchema to contain tha resolved working type rather than the original SimpleTypeDefinition. However, tampering with the redefinition level is going to stop xs:redefines working properly. Also, I can't tell where you put this fixup code and when it runs.

In this particular example, the PhoneNumber type is defined as a restriction of xs:string, so we know immediately that it is atomic. One wonders therefore why we don't do the conversion from SimpleTypeDefinition to AtomicType earlier. The only problem here is that this is a special case and doesn't tackle the general problem.

I'm trying another fix: in PreparedSchema.validate(), when we find a SimpleTypeDefinition, we now not only replace the type in the named type map for that PreparedSchema, but also for the global SuperSchema held by the Configuration. This fixes the problem for this case, I will need to do more regression testing to be sure it has no adverse effects.

Actions #6

Updated by Michael Kay about 1 year ago

  • Subject changed from Schema using redefinition fails to compile under Saxon 11 to Schema fails to compile under Saxon 11 - an imported type is held as an unresolved SimpleTypeDefinition
Actions #7

Updated by Michael Kay 10 months ago

  • Status changed from In Progress to Resolved
  • Fix Committed on Branch 11, 12, trunk added
  • Platforms .NET, Java added

I have belatedly copied the fix that was previously applied on the 12.x branch to 11.x (it didn't make it into 11.6).

Actions #8

Updated by O'Neil Delpratt 7 months ago

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

Bug fix applied in the Saxon 12.4 Maintenance release

Please register to edit this issue

Also available in: Atom PDF