Saxon

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.

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;
            }
        }

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.