Bug 355685

Comment 1 Ed Merks 2011-08-24 14:04:23 EDT

All XSD questions are answered quickly.  Unfortunately there was a period of time a couple of months ago when the synchronization between NNTP and the web forums was broken and many notes for many forums where overlooked because they simply never appeared in our NNTP news readers...

What you describe does sound problematic.  I wonder if the problem is reproducible when the schemas are in separate documents rather than nested in a WSDL...  I'll try to find time to look next week...

Comment 2 Ed Merks 2011-09-02 15:17:44 EDT

It does appear to be specific to this nested schema case.  What's happening in XSDResourceImpl is this:

    String schemaLocation = getURI().toString();
    Collection<XSDSchema> previouslyAttachedSchemas = attachedSchemas;
    attachedSchemas = null;
    for (XSDSchema xsdSchema : previouslyAttachedSchemas)
    {
      xsdSchema.setSchemaLocation(schemaLocation);
    }
    for (XSDSchema xsdSchema : previouslyAttachedSchemas)
    {
      xsdSchema.setSchemaLocation(schemaLocation);
    }

The problem is that not all the schema locations are set before analysis is performed.  Setting it a second time fixes the problem, but it rather brute force.

Changing the order of the schemas (based on dependencies) avoids the problem:

      <xs:schema targetNamespace="http://ns3">
         <xs:attributeGroup name="otherAttrGroup">
            <xs:attribute ref="ns3:problemAttribute"/>
         </xs:attributeGroup>
         <xs:attribute name="problemAttribute" type="xs:string"/>
      </xs:schema>
      <xs:schema targetNamespace="http://ns2">
         <xs:import namespace="http://ns3"/>

         <xs:complexType name="rootType"/>
         <xs:complexType name="tagNameBaseType">
            <xs:complexContent>
               <xs:extension base="ns2:rootType">
                  <xs:attributeGroup ref="ns3:otherAttrGroup"/>
                  <!--  <xs:attribute ref="ns3:problemAttribute"/> -->
               </xs:extension>
            </xs:complexContent>
         </xs:complexType>
      </xs:schema>
      <xs:schema targetNamespace="http://ns1">
         <xs:import namespace="http://ns2"/>
         <xs:element name="tagName" type="ns1:tagNameType"/>
         <xs:complexType name="tagNameType">
            <xs:complexContent>
               <xs:extension base="ns2:tagNameBaseType"/>
            </xs:complexContent>
         </xs:complexType>
      </xs:schema>

Comment 3 Anthony Hunter 2011-09-27 13:40:56 EDT

(In reply to comment #2)
> Changing the order of the schemas (based on dependencies) avoids the problem:

Paul, you never answered if this workaround was sufficient. Seems like changing the order of the schemas is something you can look at doing?

Comment 4 Paul Cooper 2011-09-28 04:50:33 EDT

(In reply to comment #3)
> (In reply to comment #2)
> > Changing the order of the schemas (based on dependencies) avoids the problem:
> 
> Paul, you never answered if this workaround was sufficient. Seems like changing
> the order of the schemas is something you can look at doing?

Was comment #2 a question? Sorry, I thought it was acknowledgement that there was indeed a bug to fix! I sure hope this hasn't blocked resolution of the problem!


No, reworking the schemas to work around the problem in XSD isn't an acceptable solution. At most it's a temporary mitigation. The original WSDL I received is from a major financial services organisation, and was supplied to me by one of their customers. I created the much smaller test-case in this bug report to demonstrate the problem whilst maintaining privacy.

I did ask my up-stream source if they'd be happy modifying their supplier's WSDL to work around the bug, but they weren't at all happy with that recommendation.

Comment 5 Anthony Hunter 2012-02-27 10:33:37 EST

(In reply to comment #2)
> It does appear to be specific to this nested schema case.  What's happening in
> XSDResourceImpl is this:
> 
>     String schemaLocation = getURI().toString();
>     Collection<XSDSchema> previouslyAttachedSchemas = attachedSchemas;
>     attachedSchemas = null;
>     for (XSDSchema xsdSchema : previouslyAttachedSchemas)
>     {
>       xsdSchema.setSchemaLocation(schemaLocation);
>     }
>     for (XSDSchema xsdSchema : previouslyAttachedSchemas)
>     {
>       xsdSchema.setSchemaLocation(schemaLocation);
>     }
> 
> The problem is that not all the schema locations are set before analysis is
> performed.  Setting it a second time fixes the problem, but it rather brute
> force.
> 

Ed, the team reports that setting it a second time fixes their issue. Adding the lines:
     for (XSDSchema xsdSchema : previouslyAttachedSchemas)
     {
       xsdSchema.setSchemaLocation(schemaLocation);
     }
fixed the issue. Is this a fix we could put in the main stream?

Comment 6 Ed Merks 2012-02-27 11:29:56 EST

It's really not a proper fix but rather a brute force solution.  It's a very expensive call that walks the whole schema and does a full analysis.  Not all clients will be happy for this expensive thing to become twice as costly.