Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » XML Schema Definition (XSD) » Handling of duplicate type definition from included XSD(What happens when the XSD pulled in using xsd:include has a duplicate type definition)
Handling of duplicate type definition from included XSD [message #517729] Mon, 01 March 2010 15:45 Go to next message
Nikita Missing name
Messages: 32
Registered: October 2009
Member
I have the following parent.xsd which I load to an XSDSchema object using an XSDResourceImpl (along with a custom XSDSchemaLocator):

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns="http://www.sandbox.com/test"
            targetNamespace="http://www.sandbox.com/test">

  <xsd:include schemaLocation="child.xsd" />

  <xsd:complexType name="person-type">
    <xsd:sequence>
      <xsd:element name="first-name" type="xsd:string"/>
      <xsd:element name="home-address" type="address-type"/>
    </xsd:sequence>
  </xsd:complexType>

  <xsd:complexType name="address-type">
    <xsd:sequence>
      <xsd:element name="city" type="xsd:string"/>
      <xsd:element name="zip-code" type="xsd:integer"/>
    </xsd:sequence>
  </xsd:complexType>
</xsd:schema>


If child.xsd also defines a type called "address-type", the duplicate type is detected, and this diagnostic error is added: The type may not have duplicate name and target namespace 'http://www.sandbox.com/test#address-type' (coss-schema.2).

I have a couple questions on how this situation is handled:
1. Is it safe to assume that even though there are 2 definitions of the same type, the definition from the parent XSD will be used by other types within that XSD? In this example, person-type would point to the address-type defined in parent.xsd, not the one in child.xsd.
2. Is the diagnostics list the best way to determine the list of all duplicate types? How can I get to the actual conflicted XSDTypeDefinition objects?

Thank you!
Nikita
Re: Handling of duplicate type definition from included XSD [message #517734 is a reply to message #517729] Mon, 01 March 2010 16:02 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25739
Registered: July 2009
Senior Member
Nikita,

Comments below.


Nikita wrote:
> I have the following parent.xsd which I load to an XSDSchema object
> using an XSDResourceImpl (along with a custom XSDSchemaLocator):
>
> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns="http://www.sandbox.com/test"
> targetNamespace="http://www.sandbox.com/test">
>
> <xsd:include schemaLocation="child.xsd" />
>
> <xsd:complexType name="person-type">
> <xsd:sequence>
> <xsd:element name="first-name" type="xsd:string"/>
> <xsd:element name="home-address" type="address-type"/>
> </xsd:sequence>
> </xsd:complexType>
>
> <xsd:complexType name="address-type">
> <xsd:sequence>
> <xsd:element name="city" type="xsd:string"/>
> <xsd:element name="zip-code" type="xsd:integer"/>
> </xsd:sequence>
> </xsd:complexType>
> </xsd:schema>
>
> If child.xsd also defines a type called "address-type", the duplicate
> type is detected, and this diagnostic error is added: The type may
> not have duplicate name and target namespace
> 'http://www.sandbox.com/test#address-type' (coss-schema.2).
>
> I have a couple questions on how this situation is handled:
> 1. Is it safe to assume that even though there are 2 definitions of
> the same type, the definition from the parent XSD will be used by
> other types within that XSD?
No, I wouldn't assume that.
> In this example, person-type would point to the address-type defined
> in parent.xsd, not the one in child.xsd.
That might be the case, but I wouldn't count on it.
> 2. Is the diagnostics list the best way to determine the list of all
> duplicate types? How can I get to the actual conflicted
> XSDTypeDefinition objects?
The diagnostic's primary component should be the local declaration
that's causing the problem, if there is a local declaration; they might
each come from included schemas and not be a problem until combined in
the including schema.
>
> Thank you!
> Nikita
Re: Handling of duplicate type definition from included XSD [message #517925 is a reply to message #517734] Tue, 02 March 2010 09:38 Go to previous messageGo to next message
Nikita Missing name
Messages: 32
Registered: October 2009
Member
Hi Ed,

Thank you for the reply. I am having trouble with the last part:

> The diagnostic's primary component should be the local declaration
> that's causing the problem, if there is a local declaration; they might
> each come from included schemas and not be a problem until combined in
> the including schema.

When I get the component of the diagnostic, sometimes it's an XSDComplexTypeDefinitionImpl and sometimes it's an XSDSchemaImpl. The different values happen on the exact same XSDs and code.

Here is how I output the diagnostics:
  private static void outputDiagnostics(XSDSchema xsd) {
    if (xsd.getAllDiagnostics().isEmpty()) {
      xsd.validate();
    }
    List<XSDDiagnostic> diagnostics = xsd.getAllDiagnostics();
    if (diagnostics.isEmpty()) {
      return;
    } else {
      System.out.println("Diagnostics for "+xsd);
      for (XSDDiagnostic d : diagnostics) {
        System.out.println(d.getKey()+": "+d.getMessage()+": "+d.getComponents());
      }
    }
  }


These are the 2 different outputs I see intermittently:
coss-schema.2: XSD: The type may not have duplicate name and target namespace 'http://www.sandbox.com/test#address-type': [org.eclipse.xsd.impl.XSDComplexTypeDefinitionImpl@1c5fde0 (element: [xsd:complexType: null]) (name: address-type, targetNamespace: http://www.sandbox.com/test) (derivationMethod: <unset>, final: [], abstract: <unset>, contentTypeCategory: elementOnly, prohibitedSubstitutions: [], lexicalFinal: null, block: null, mixed: <unset>)]


coss-schema.2: XSD: The type may not have duplicate name and target namespace 'http://www.sandbox.com/test#address-type': [org.eclipse.xsd.impl.XSDSchemaImpl@47b35d (element: [xsd:schema: null]) (document: [#document: null], schemaLocation: myResource2, targetNamespace: http://www.sandbox.com/test, attributeFormDefault: <unset>, elementFormDefault: <unset>, finalDefault: [], blockDefault: [], version: null)]


Thank you,
Nikita
Re: Handling of duplicate type definition from included XSD [message #517943 is a reply to message #517925] Tue, 02 March 2010 09:54 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 25739
Registered: July 2009
Senior Member
Nikita,

It really depends on the order in the overall list of components, which
are sorted, but I don't think the sorting algorithm is stable for equal
keys. In general, you can't assume you'll get the component from the
diagnostic because each component could have come from a different
schema and are a problem only when both schemas are included in a third
schema.

Probably you'd be better of to use the substitutions of the diagnostic
to find the URI of the duplicate, and then find all the matches
XSDNamedComponent.hasNameAndTargetNamespace in the list of types.


Nikita wrote:
> Hi Ed,
>
> Thank you for the reply. I am having trouble with the last part:
>
>> The diagnostic's primary component should be the local declaration
>> that's causing the problem, if there is a local declaration; they
>> might each come from included schemas and not be a problem until
>> combined in the including schema.
>
> When I get the component of the diagnostic, sometimes it's an
> XSDComplexTypeDefinitionImpl and sometimes it's an XSDSchemaImpl. The
> different values happen on the exact same XSDs and code.
>
> Here is how I output the diagnostics:
> private static void outputDiagnostics(XSDSchema xsd) {
> if (xsd.getAllDiagnostics().isEmpty()) {
> xsd.validate();
> }
> List<XSDDiagnostic> diagnostics = xsd.getAllDiagnostics();
> if (diagnostics.isEmpty()) {
> return;
> } else {
> System.out.println("Diagnostics for "+xsd);
> for (XSDDiagnostic d : diagnostics) {
> System.out.println(d.getKey()+": "+d.getMessage()+":
> "+d.getComponents());
> }
> }
> }
>
>
> These are the 2 different outputs I see intermittently:
>
> coss-schema.2: XSD: The type may not have duplicate name and target
> namespace 'http://www.sandbox.com/test#address-type':
> [org.eclipse.xsd.impl.XSDComplexTypeDefinitionImpl@1c5fde0 (element:
> [xsd:complexType: null]) (name: address-type, targetNamespace:
> http://www.sandbox.com/test) (derivationMethod: <unset>, final: [],
> abstract: <unset>, contentTypeCategory: elementOnly,
> prohibitedSubstitutions: [], lexicalFinal: null, block: null, mixed:
> <unset>)]
>
>
>
> coss-schema.2: XSD: The type may not have duplicate name and target
> namespace 'http://www.sandbox.com/test#address-type':
> [org.eclipse.xsd.impl.XSDSchemaImpl@47b35d (element: [xsd:schema:
> null]) (document: [#document: null], schemaLocation: myResource2,
> targetNamespace: http://www.sandbox.com/test, attributeFormDefault:
> <unset>, elementFormDefault: <unset>, finalDefault: [], blockDefault:
> [], version: null)]
>
>
> Thank you,
> Nikita
Re: Handling of duplicate type definition from included XSD [message #604524 is a reply to message #517734] Tue, 02 March 2010 09:38 Go to previous message
Nikita Missing name
Messages: 32
Registered: October 2009
Member
Hi Ed,

Thank you for the reply. I am having trouble with the last part:

> The diagnostic's primary component should be the local declaration
> that's causing the problem, if there is a local declaration; they might
> each come from included schemas and not be a problem until combined in
> the including schema.

When I get the component of the diagnostic, sometimes it's an XSDComplexTypeDefinitionImpl and sometimes it's an XSDSchemaImpl. The different values happen on the exact same XSDs and code.

Here is how I output the diagnostics:
private static void outputDiagnostics(XSDSchema xsd) {
if (xsd.getAllDiagnostics().isEmpty()) {
xsd.validate();
}
List<XSDDiagnostic> diagnostics = xsd.getAllDiagnostics();
if (diagnostics.isEmpty()) {
return;
} else {
System.out.println("Diagnostics for "+xsd);
for (XSDDiagnostic d : diagnostics) {
System.out.println(d.getKey()+": "+d.getMessage()+": "+d.getComponents());
}
}
}


These are the 2 different outputs I see intermittently:

coss-schema.2: XSD: The type may not have duplicate name and target namespace 'http://www.sandbox.com/test#address-type': [org.eclipse.xsd.impl.XSDComplexTypeDefinitionImpl@1c5fde0 (element: [xsd:complexType: null]) (name: address-type, targetNamespace: http://www.sandbox.com/test) (derivationMethod: <unset>, final: [], abstract: <unset>, contentTypeCategory: elementOnly, prohibitedSubstitutions: [], lexicalFinal: null, block: null, mixed: <unset>)]



coss-schema.2: XSD: The type may not have duplicate name and target namespace 'http://www.sandbox.com/test#address-type': [org.eclipse.xsd.impl.XSDSchemaImpl@47b35d (element: [xsd:schema: null]) (document: [#document: null], schemaLocation: myResource2, targetNamespace: http://www.sandbox.com/test, attributeFormDefault: <unset>, elementFormDefault: <unset>, finalDefault: [], blockDefault: [], version: null)]


Thank you,
Nikita
Re: Handling of duplicate type definition from included XSD [message #604527 is a reply to message #604524] Tue, 02 March 2010 09:54 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 25739
Registered: July 2009
Senior Member
Nikita,

It really depends on the order in the overall list of components, which
are sorted, but I don't think the sorting algorithm is stable for equal
keys. In general, you can't assume you'll get the component from the
diagnostic because each component could have come from a different
schema and are a problem only when both schemas are included in a third
schema.

Probably you'd be better of to use the substitutions of the diagnostic
to find the URI of the duplicate, and then find all the matches
XSDNamedComponent.hasNameAndTargetNamespace in the list of types.


Nikita wrote:
> Hi Ed,
>
> Thank you for the reply. I am having trouble with the last part:
>
>> The diagnostic's primary component should be the local declaration
>> that's causing the problem, if there is a local declaration; they
>> might each come from included schemas and not be a problem until
>> combined in the including schema.
>
> When I get the component of the diagnostic, sometimes it's an
> XSDComplexTypeDefinitionImpl and sometimes it's an XSDSchemaImpl. The
> different values happen on the exact same XSDs and code.
>
> Here is how I output the diagnostics:
> private static void outputDiagnostics(XSDSchema xsd) {
> if (xsd.getAllDiagnostics().isEmpty()) {
> xsd.validate();
> }
> List<XSDDiagnostic> diagnostics = xsd.getAllDiagnostics();
> if (diagnostics.isEmpty()) {
> return;
> } else {
> System.out.println("Diagnostics for "+xsd);
> for (XSDDiagnostic d : diagnostics) {
> System.out.println(d.getKey()+": "+d.getMessage()+":
> "+d.getComponents());
> }
> }
> }
>
>
> These are the 2 different outputs I see intermittently:
>
> coss-schema.2: XSD: The type may not have duplicate name and target
> namespace 'http://www.sandbox.com/test#address-type':
> [org.eclipse.xsd.impl.XSDComplexTypeDefinitionImpl@1c5fde0 (element:
> [xsd:complexType: null]) (name: address-type, targetNamespace:
> http://www.sandbox.com/test) (derivationMethod: <unset>, final: [],
> abstract: <unset>, contentTypeCategory: elementOnly,
> prohibitedSubstitutions: [], lexicalFinal: null, block: null, mixed:
> <unset>)]
>
>
>
> coss-schema.2: XSD: The type may not have duplicate name and target
> namespace 'http://www.sandbox.com/test#address-type':
> [org.eclipse.xsd.impl.XSDSchemaImpl@47b35d (element: [xsd:schema:
> null]) (document: [#document: null], schemaLocation: myResource2,
> targetNamespace: http://www.sandbox.com/test, attributeFormDefault:
> <unset>, elementFormDefault: <unset>, finalDefault: [], blockDefault:
> [], version: null)]
>
>
> Thank you,
> Nikita
Previous Topic:Handling of duplicate type definition from included XSD
Next Topic:XSD->Ecore->XSD and anonymous types
Goto Forum:
  


Current Time: Wed Apr 16 00:23:33 EDT 2014

Powered by FUDForum. Page generated in 0.01878 seconds