SoapUI not reporting schema problem that SchemaFactory#newSchema throws as src-resolve.4.2 error

EDIT: Clarified details about the SchemaFactory class.

----

I believe I've run into an XSD namespace handling discrepancy between the SoapUI libraries and the WSDL4J library's javax.xml.validation.SchemaFactory class. I'm specifically utilizing WSDL4J v1.6.3.

NB: For the sake of security, I'll be obfuscating with placeholder filenames and namespaces.

I've a third-party WSDL, "Service.wsdl," that imports a single XSD, "ServiceSchema.xsd." ServiceSchema.xsd then imports a few more XSDs: "ServiceSpecificEntities.xsd," "CommonDefinitions1.xsd," and "CommonDefinitions2.xsd." ServiceSpecificEntities.xsd defines prefixes for namespaces that are targeted by the other two XSDs. However, it never directly imports those XSDs itself.

A visual representation of the original XSD import chain ("-<-" indicates the LHS file importing the RHS file):

Service.wsdl -<- ServiceSchema.xsd -<- ServiceSpecificEntities.xsd
                                       * Declares prefix "ns1" as namespace "urn:org:organization"
                                       * Declares prefix "ns2" as namespace "urn:org:organization:service"
                                       ! Imports neither CommonDefinitions1.xsd nor CommonDefinitions2.xsd
                                   -<- CommonDefinitions1.xsd
                                       * Targets namespace "urn:org:organization"
                                   -<- CommonDefinitions2.xsd
                                       * Targets namespace "urn:org:organization:service"

In my own code, a new javax.xml.validation.Schema object is instantiated via SchemaFactory#newSchema(...). The method receives ServiceSchema.xsd as an explicit parameter. On call, the method throws an org.xml.sax.SAXParseException with the message:

src-resolve.4.2: Error resolving component 'ns1:commonEntity'. It was
detected that 'ns1:commonEntity' is in namespace 'urn:org:organization',
but components from this namespace are not referenceable from schema
document 'file:/ServiceSpecificEntities.xsd'. If this is the incorrect
namespace, perhaps the prefix of 'ns1:commonEntity' needs to be changed.
If this is the correct namespace, then an appropriate 'import' tag
should be added to 'file:/ServiceSpecificEntities.xsd'.

SoapUI, however, loads the WSDL and validates both request and response XML without a peep.

When I edit the third-party ServiceSpecificEntities.xsd, adding import tags for CommonDefinitions1.xsd and CommonDefinitions2.xsd, the SchemaFactory#newSchema(...) call no longer throws an exception. This is the resulting import chain: 

Service.wsdl -<- ServiceSchema.xsd -<- ServiceSpecificEntities.xsd -<- CommonDefinitions1.xsd
                                                                   -<- CommonDefinitions2.xsd
                                   -<- CommonDefinitions1.xsd
                                   -<- CommonDefinitions2.xsd

From the facts that adding the imports stops the SAXParseException, and the additions don't break SoapUI, I've inferred there's an overlooked dependency in my third-party schema that SoapUI resolves. However, the built-in Java SchemaFactory either can't or won't (the exception message does mention detecting the commonEntity component despite it being out of scope).

Is SoapUI's lack of exception intended behavior? Is there some looser XSD specification utilized by WSDLs that I'm not aware of?

Please advise,

Dan C. Wlodarski