Skip to main content

 Eclipse Community Forums Forum Search:

Home » Eclipse Projects » XML Schema Definition (XSD) » redefine
redefine Tue, 23 March 2004 23:20
 Eclipse User
Originally posted by: jtaylor.nextance.com

Hello,
If I understand the W3C spec correctly, a redefined complexType should be
used everywhere in place of the original type. For example, if I use the
redefined complexType as a base type for another type, the derived type
should now include the additional elements introduced by the redefined
type. This is not the behavior I'm seeing in Eclipse XSD. When I get the
base type, using complexTypeDefinition.getBaseType(), I continue to get
the original definition instead of the redefined one. References to the
type within the schema that has the redefine do point to the new redefined
type, though. Is this intentional? Should I use a different mechanism to
get the base type? Or is this a bug?

Thanks,

James
Re: redefine [message #39474 is a reply to message #39443] Wed, 24 March 2004 00:00
 Eclipse User
Originally posted by: merks.ca.ibm.com

James,

I'm not sure I can really answer the details of your questions without clear
references to particular components in actual schema documents, i.e., a
sample. Perhaps it helps to explain that redefinition is accomplished by
making a clone of the schema being redefined and then modifying that copy
according to the redefinition. The original schema is not touched; it may be
redefined many times in many different ways. The schema containing the
redefine will see only the copy, not the original. Which version you get will
depend very much on where you ask, so you need to be specific...

James Taylor wrote:

> Hello,
> If I understand the W3C spec correctly, a redefined complexType should be
> used everywhere in place of the original type. For example, if I use the
> redefined complexType as a base type for another type, the derived type
> should now include the additional elements introduced by the redefined
> type. This is not the behavior I'm seeing in Eclipse XSD. When I get the
> base type, using complexTypeDefinition.getBaseType(), I continue to get
> the original definition instead of the redefined one. References to the
> type within the schema that has the redefine do point to the new redefined
> type, though. Is this intentional? Should I use a different mechanism to
> get the base type? Or is this a bug?
>
> Thanks,
>
> James
Re: redefine [message #39505 is a reply to message #39474] Wed, 24 March 2004 00:38
 Eclipse User
Originally posted by: jtaylor.nextance.com

Ed,

Thanks for the reply. My sample is below. In v4.xsd, I would have
expected that the "marriedPeople" element would contain the "generation"
element since it is redefined to include this in v2.xsd. The
"singlePeople" element does include the "generation" element as expected.

Thanks,

James

v1.xsd:
<xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
xmlns:test="http://namespaces.nextance.com/nex/test"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="unqualified" attributeFormDefault="unqualified">
<xs:complexType name="personName">
<xs:sequence>
<xs:element name="title" type="xs:string" minOccurs="0"/>
<xs:element name="forename" type="xs:string" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>

<xs:element name="addressee" type="test:personName"/>
</xs:schema>

v2.xsd:
<xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
xmlns:test="http://namespaces.nextance.com/nex/test"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="unqualified" attributeFormDefault="unqualified">
<xs:redefine schemaLocation="v1.xsd">
<xs:complexType name="personName">
<xs:complexContent>
<xs:extension base="test:personName">
<xs:sequence>
<xs:element name="generation" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:redefine>

<xs:element name="author" type="test:personName"/>
</xs:schema>

v3.xsd:
<xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
xmlns:test="http://namespaces.nextance.com/nex/test"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="unqualified" attributeFormDefault="unqualified">
<xs:include schemaLocation="v1.xsd"/>

<xs:complexType name="marriedPersonName">
<xs:complexContent>
<xs:extension base="test:personName">
<xs:sequence>
<xs:element name="maidenName" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>

<xs:element name="marriedPerson" type="test:marriedPersonName"/>

</xs:schema>

v4.xsd:
<xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
xmlns:test="http://namespaces.nextance.com/nex/test"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="unqualified" attributeFormDefault="unqualified">
<xs:include schemaLocation="v2.xsd"/>
<xs:include schemaLocation="v3.xsd"/>

<xs:complexType name="people">
<xs:sequence>
<xs:element name="marriedPeople" type="test:marriedPersonName"
maxOccurs="unbounded"/>
<xs:element name="singlePeople" type="test:personName"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:element name="directory" type="test:people"/>
</xs:schema>

Ed Merks wrote:

> James,

> I'm not sure I can really answer the details of your questions without clear
> references to particular components in actual schema documents, i.e., a
> sample. Perhaps it helps to explain that redefinition is accomplished by
> making a clone of the schema being redefined and then modifying that copy
> according to the redefinition. The original schema is not touched; it may be
> redefined many times in many different ways. The schema containing the
> redefine will see only the copy, not the original. Which version you get will
> depend very much on where you ask, so you need to be specific...

> James Taylor wrote:

> > Hello,
> > If I understand the W3C spec correctly, a redefined complexType should be
> > used everywhere in place of the original type. For example, if I use the
> > redefined complexType as a base type for another type, the derived type
> > should now include the additional elements introduced by the redefined
> > type. This is not the behavior I'm seeing in Eclipse XSD. When I get the
> > base type, using complexTypeDefinition.getBaseType(), I continue to get
> > the original definition instead of the redefined one. References to the
> > type within the schema that has the redefine do point to the new redefined
> > type, though. Is this intentional? Should I use a different mechanism to
> > get the base type? Or is this a bug?
> >
> > Thanks,
> >
> > James
Re: redefine [message #39536 is a reply to message #39505] Wed, 24 March 2004 12:57
 Eclipse User
Originally posted by: merks.ca.ibm.com

James,

The v4.xsd schema isn't valid because its includes both a redefined version of
personName and addressee, via its include of v2.xsd's redefinition of v1.xsd, as
well as the original version of personName and addressee, via its include of
v3.xsd's include of v1.xsd without redefinition. The v3.xsd schema needs to
include v2.xsd not v1.xsd for this example to be valid. The bottom line is that
v1.xsd is not modified by virtue of the redefine in v2.xsd; only v2.xsd sees that
redefinition directly and any schema importing or including v2.xsd will see that
redefinition indirectly; but v3.xsd sees only the original v1.xsd and knows nothing
of v2.xsd. When we get to v4.xsd, the result is name collision.

James Taylor wrote:

> Ed,
>
> Thanks for the reply. My sample is below. In v4.xsd, I would have
> expected that the "marriedPeople" element would contain the "generation"
> element since it is redefined to include this in v2.xsd. The
> "singlePeople" element does include the "generation" element as expected.
>
> Thanks,
>
> James
>
> v1.xsd:
> <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> xmlns:test="http://namespaces.nextance.com/nex/test"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="unqualified" attributeFormDefault="unqualified">
> <xs:complexType name="personName">
> <xs:sequence>
> <xs:element name="title" type="xs:string" minOccurs="0"/>
> <xs:element name="forename" type="xs:string" minOccurs="0"
> maxOccurs="unbounded"/>
> </xs:sequence>
> </xs:complexType>
>
> <xs:element name="addressee" type="test:personName"/>
> </xs:schema>
>
> v2.xsd:
> <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> xmlns:test="http://namespaces.nextance.com/nex/test"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="unqualified" attributeFormDefault="unqualified">
> <xs:redefine schemaLocation="v1.xsd">
> <xs:complexType name="personName">
> <xs:complexContent>
> <xs:extension base="test:personName">
> <xs:sequence>
> <xs:element name="generation" type="xs:string" minOccurs="0"/>
> </xs:sequence>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
> </xs:redefine>
>
> <xs:element name="author" type="test:personName"/>
> </xs:schema>
>
> v3.xsd:
> <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> xmlns:test="http://namespaces.nextance.com/nex/test"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="unqualified" attributeFormDefault="unqualified">
> <xs:include schemaLocation="v1.xsd"/>
>
> <xs:complexType name="marriedPersonName">
> <xs:complexContent>
> <xs:extension base="test:personName">
> <xs:sequence>
> <xs:element name="maidenName" type="xs:string" minOccurs="0"/>
> </xs:sequence>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
>
> <xs:element name="marriedPerson" type="test:marriedPersonName"/>
>
> </xs:schema>
>
> v4.xsd:
> <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> xmlns:test="http://namespaces.nextance.com/nex/test"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="unqualified" attributeFormDefault="unqualified">
> <xs:include schemaLocation="v2.xsd"/>
> <xs:include schemaLocation="v3.xsd"/>
>
> <xs:complexType name="people">
> <xs:sequence>
> <xs:element name="marriedPeople" type="test:marriedPersonName"
> maxOccurs="unbounded"/>
> <xs:element name="singlePeople" type="test:personName"
> maxOccurs="unbounded"/>
> </xs:sequence>
> </xs:complexType>
> <xs:element name="directory" type="test:people"/>
> </xs:schema>
>
> Ed Merks wrote:
>
> > James,
>
> > I'm not sure I can really answer the details of your questions without clear
> > references to particular components in actual schema documents, i.e., a
> > sample. Perhaps it helps to explain that redefinition is accomplished by
> > making a clone of the schema being redefined and then modifying that copy
> > according to the redefinition. The original schema is not touched; it may be
> > redefined many times in many different ways. The schema containing the
> > redefine will see only the copy, not the original. Which version you get will
> > depend very much on where you ask, so you need to be specific...
>
> > James Taylor wrote:
>
> > > Hello,
> > > If I understand the W3C spec correctly, a redefined complexType should be
> > > used everywhere in place of the original type. For example, if I use the
> > > redefined complexType as a base type for another type, the derived type
> > > should now include the additional elements introduced by the redefined
> > > type. This is not the behavior I'm seeing in Eclipse XSD. When I get the
> > > base type, using complexTypeDefinition.getBaseType(), I continue to get
> > > the original definition instead of the redefined one. References to the
> > > type within the schema that has the redefine do point to the new redefined
> > > type, though. Is this intentional? Should I use a different mechanism to
> > > get the base type? Or is this a bug?
> > >
> > > Thanks,
> > >
> > > James
Re: redefine [message #39780 is a reply to message #39536] Thu, 25 March 2004 02:09
 Eclipse User
Originally posted by: jtaylor.nextance.com

Ed,

Thank you for the explanation. It's not clear to me how "pervasive" the
W3C spec
( http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#modify-s chema) meant
a redefine to be when they state:

The modifications have a pervasive impact, that is, only the redefined
components are used, even when referenced from other incorporated
components, whether redefined themselves or not.

Given that later in the spec they imply that multiple redefines of the
same type that conflict are not legal, I assume they meant that the
redefined type should "pervade" everywhere, including in my example of
v4.xsd.

James

Ed Merks wrote:

> James,

> The v4.xsd schema isn't valid because its includes both a redefined version
of
> personName and addressee, via its include of v2.xsd's redefinition of
v1.xsd, as
> well as the original version of personName and addressee, via its include of
> v3.xsd's include of v1.xsd without redefinition. The v3.xsd schema needs to
> include v2.xsd not v1.xsd for this example to be valid. The bottom line is
that
> v1.xsd is not modified by virtue of the redefine in v2.xsd; only v2.xsd sees
that
> redefinition directly and any schema importing or including v2.xsd will see
that
> redefinition indirectly; but v3.xsd sees only the original v1.xsd and knows
nothing
> of v2.xsd. When we get to v4.xsd, the result is name collision.

> James Taylor wrote:

> > Ed,
> >
> > Thanks for the reply. My sample is below. In v4.xsd, I would have
> > expected that the "marriedPeople" element would contain the "generation"
> > element since it is redefined to include this in v2.xsd. The
> > "singlePeople" element does include the "generation" element as expected.
> >
> > Thanks,
> >
> > James
> >
> > v1.xsd:
> > <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> > xmlns:test="http://namespaces.nextance.com/nex/test"
> > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > <xs:complexType name="personName">
> > <xs:sequence>
> > <xs:element name="title" type="xs:string" minOccurs="0"/>
> > <xs:element name="forename" type="xs:string" minOccurs="0"
> > maxOccurs="unbounded"/>
> > </xs:sequence>
> > </xs:complexType>
> >
> > <xs:element name="addressee" type="test:personName"/>
> > </xs:schema>
> >
> > v2.xsd:
> > <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> > xmlns:test="http://namespaces.nextance.com/nex/test"
> > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > <xs:redefine schemaLocation="v1.xsd">
> > <xs:complexType name="personName">
> > <xs:complexContent>
> > <xs:extension base="test:personName">
> > <xs:sequence>
> > <xs:element name="generation" type="xs:string" minOccurs="0"/>
> > </xs:sequence>
> > </xs:extension>
> > </xs:complexContent>
> > </xs:complexType>
> > </xs:redefine>
> >
> > <xs:element name="author" type="test:personName"/>
> > </xs:schema>
> >
> > v3.xsd:
> > <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> > xmlns:test="http://namespaces.nextance.com/nex/test"
> > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > <xs:include schemaLocation="v1.xsd"/>
> >
> > <xs:complexType name="marriedPersonName">
> > <xs:complexContent>
> > <xs:extension base="test:personName">
> > <xs:sequence>
> > <xs:element name="maidenName" type="xs:string" minOccurs="0"/>
> > </xs:sequence>
> > </xs:extension>
> > </xs:complexContent>
> > </xs:complexType>
> >
> > <xs:element name="marriedPerson" type="test:marriedPersonName"/>
> >
> > </xs:schema>
> >
> > v4.xsd:
> > <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> > xmlns:test="http://namespaces.nextance.com/nex/test"
> > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > <xs:include schemaLocation="v2.xsd"/>
> > <xs:include schemaLocation="v3.xsd"/>
> >
> > <xs:complexType name="people">
> > <xs:sequence>
> > <xs:element name="marriedPeople" type="test:marriedPersonName"
> > maxOccurs="unbounded"/>
> > <xs:element name="singlePeople" type="test:personName"
> > maxOccurs="unbounded"/>
> > </xs:sequence>
> > </xs:complexType>
> > <xs:element name="directory" type="test:people"/>
> > </xs:schema>
> >
> > Ed Merks wrote:
> >
> > > James,
> >
> > > I'm not sure I can really answer the details of your questions without
clear
> > > references to particular components in actual schema documents, i.e., a
> > > sample. Perhaps it helps to explain that redefinition is accomplished by
> > > making a clone of the schema being redefined and then modifying that copy
> > > according to the redefinition. The original schema is not touched; it
may be
> > > redefined many times in many different ways. The schema containing the
> > > redefine will see only the copy, not the original. Which version you get
will
> > > depend very much on where you ask, so you need to be specific...
> >
> > > James Taylor wrote:
> >
> > > > Hello,
> > > > If I understand the W3C spec correctly, a redefined complexType should
be
> > > > used everywhere in place of the original type. For example, if I use
the
> > > > redefined complexType as a base type for another type, the derived type
> > > > should now include the additional elements introduced by the redefined
> > > > type. This is not the behavior I'm seeing in Eclipse XSD. When I get
the
> > > > base type, using complexTypeDefinition.getBaseType(), I continue to get
> > > > the original definition instead of the redefined one. References to
the
> > > > type within the schema that has the redefine do point to the new
redefined
> > > > type, though. Is this intentional? Should I use a different
mechanism to
> > > > get the base type? Or is this a bug?
> > > >
> > > > Thanks,
> > > >
> > > > James
Re: redefine [message #39811 is a reply to message #39780] Thu, 25 March 2004 11:37
 Eclipse User
Originally posted by: merks.ca.ibm.com

James,

All the components of the schema mentioned in the redefine are incorporated (i.e.,
cloned) and the redefinitions are pervasively applied to all the components in that
clone. Note that if the schema being redefined has a null target namespace, it may
be redefined in multiple schemas each with a different namespace and each in a
different way; in this case, during incorporation, the namespace of the clone is
modified to match the namespace of the redefining schema and the other redefinition
modifications are applied as well. In any event, the original schema remains
untouched so that it can and will be reused in its pristine form when referenced
directly.

James Taylor wrote:

> Ed,
>
> Thank you for the explanation. It's not clear to me how "pervasive" the
> W3C spec
> ( http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#modify-s chema) meant
> a redefine to be when they state:
>
> The modifications have a pervasive impact, that is, only the redefined
> components are used, even when referenced from other incorporated
> components, whether redefined themselves or not.
>
> Given that later in the spec they imply that multiple redefines of the
> same type that conflict are not legal, I assume they meant that the
> redefined type should "pervade" everywhere, including in my example of
> v4.xsd.
>
> James
>
> Ed Merks wrote:
>
> > James,
>
> > The v4.xsd schema isn't valid because its includes both a redefined version
> of
> > personName and addressee, via its include of v2.xsd's redefinition of
> v1.xsd, as
> > well as the original version of personName and addressee, via its include of
> > v3.xsd's include of v1.xsd without redefinition. The v3.xsd schema needs to
> > include v2.xsd not v1.xsd for this example to be valid. The bottom line is
> that
> > v1.xsd is not modified by virtue of the redefine in v2.xsd; only v2.xsd sees
> that
> > redefinition directly and any schema importing or including v2.xsd will see
> that
> > redefinition indirectly; but v3.xsd sees only the original v1.xsd and knows
> nothing
> > of v2.xsd. When we get to v4.xsd, the result is name collision.
>
> > James Taylor wrote:
>
> > > Ed,
> > >
> > > Thanks for the reply. My sample is below. In v4.xsd, I would have
> > > expected that the "marriedPeople" element would contain the "generation"
> > > element since it is redefined to include this in v2.xsd. The
> > > "singlePeople" element does include the "generation" element as expected.
> > >
> > > Thanks,
> > >
> > > James
> > >
> > > v1.xsd:
> > > <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > <xs:complexType name="personName">
> > > <xs:sequence>
> > > <xs:element name="title" type="xs:string" minOccurs="0"/>
> > > <xs:element name="forename" type="xs:string" minOccurs="0"
> > > maxOccurs="unbounded"/>
> > > </xs:sequence>
> > > </xs:complexType>
> > >
> > > <xs:element name="addressee" type="test:personName"/>
> > > </xs:schema>
> > >
> > > v2.xsd:
> > > <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > <xs:redefine schemaLocation="v1.xsd">
> > > <xs:complexType name="personName">
> > > <xs:complexContent>
> > > <xs:extension base="test:personName">
> > > <xs:sequence>
> > > <xs:element name="generation" type="xs:string" minOccurs="0"/>
> > > </xs:sequence>
> > > </xs:extension>
> > > </xs:complexContent>
> > > </xs:complexType>
> > > </xs:redefine>
> > >
> > > <xs:element name="author" type="test:personName"/>
> > > </xs:schema>
> > >
> > > v3.xsd:
> > > <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > <xs:include schemaLocation="v1.xsd"/>
> > >
> > > <xs:complexType name="marriedPersonName">
> > > <xs:complexContent>
> > > <xs:extension base="test:personName">
> > > <xs:sequence>
> > > <xs:element name="maidenName" type="xs:string" minOccurs="0"/>
> > > </xs:sequence>
> > > </xs:extension>
> > > </xs:complexContent>
> > > </xs:complexType>
> > >
> > > <xs:element name="marriedPerson" type="test:marriedPersonName"/>
> > >
> > > </xs:schema>
> > >
> > > v4.xsd:
> > > <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > <xs:include schemaLocation="v2.xsd"/>
> > > <xs:include schemaLocation="v3.xsd"/>
> > >
> > > <xs:complexType name="people">
> > > <xs:sequence>
> > > <xs:element name="marriedPeople" type="test:marriedPersonName"
> > > maxOccurs="unbounded"/>
> > > <xs:element name="singlePeople" type="test:personName"
> > > maxOccurs="unbounded"/>
> > > </xs:sequence>
> > > </xs:complexType>
> > > <xs:element name="directory" type="test:people"/>
> > > </xs:schema>
> > >
> > > Ed Merks wrote:
> > >
> > > > James,
> > >
> > > > I'm not sure I can really answer the details of your questions without
> clear
> > > > references to particular components in actual schema documents, i.e., a
> > > > sample. Perhaps it helps to explain that redefinition is accomplished by
> > > > making a clone of the schema being redefined and then modifying that copy
> > > > according to the redefinition. The original schema is not touched; it
> may be
> > > > redefined many times in many different ways. The schema containing the
> > > > redefine will see only the copy, not the original. Which version you get
> will
> > > > depend very much on where you ask, so you need to be specific...
> > >
> > > > James Taylor wrote:
> > >
> > > > > Hello,
> > > > > If I understand the W3C spec correctly, a redefined complexType should
> be
> > > > > used everywhere in place of the original type. For example, if I use
> the
> > > > > redefined complexType as a base type for another type, the derived type
> > > > > should now include the additional elements introduced by the redefined
> > > > > type. This is not the behavior I'm seeing in Eclipse XSD. When I get
> the
> > > > > base type, using complexTypeDefinition.getBaseType(), I continue to get
> > > > > the original definition instead of the redefined one. References to
> the
> > > > > type within the schema that has the redefine do point to the new
> redefined
> > > > > type, though. Is this intentional? Should I use a different
> mechanism to
> > > > > get the base type? Or is this a bug?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > James
Re: redefine [message #39904 is a reply to message #39811] Thu, 25 March 2004 23:50
 Eclipse User
Originally posted by: jtaylor.nextance.com

Ed,

Here's a smaller more realistic example that illustrates an issue:

File A defines Employee type
File B includes File A and defines Department type
File C includes File B, redefines Employee from File A and defines Company
type

This is a common use case for redefine in which a type in a nested include
needs to be redefined. With Eclipse XSD, the redefine does not affect the
Employee type within the Department type and affects the Employee type
within the Company type only if the include of File B precedes the
redefine of File A. This does not seem like the correct behavior.

I've included the XSD files below. Thanks,

James

Employee.xsd:
<xs:schema targetNamespace="http://namespaces.nextance.com/test"
xmlns:test="http://namespaces.nextance.com/test"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="unqualified" attributeFormDefault="unqualified">
<xs:complexType name="Employee">
<xs:sequence>
<xs:element name="name" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:schema>

Department.xsd:
<xs:schema targetNamespace="http://namespaces.nextance.com/test"
xmlns:test="http://namespaces.nextance.com/test"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="unqualified" attributeFormDefault="unqualified">
<xs:include schemaLocation="Employee.xsd"/>

<xs:complexType name="Department">
<xs:sequence>
<xs:element name="employee" type="test:Employee"
maxOccurs="unbounded"/>
<xs:element name="manager" type="test:Employee"/>
</xs:sequence>
</xs:complexType>
</xs:schema>

Company.xsd:
<xs:schema targetNamespace="http://namespaces.nextance.com/test"
xmlns:test="http://namespaces.nextance.com/test"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="unqualified" attributeFormDefault="unqualified">

<xs:include schemaLocation="Department.xsd"/>

<xs:redefine schemaLocation="Employee.xsd">
<xs:complexType name="Employee">
<xs:complexContent>
<xs:extension base="test:Employee">
<xs:sequence>
<xs:element name="ranking" type="xs:int"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:redefine>

<xs:complexType name="Company">
<xs:sequence>
<xs:element name="department" type="test:Department"
maxOccurs="unbounded"/>
<xs:element name="president" type="test:Employee"/>
</xs:sequence>
</xs:complexType>

<xs:element name="fortune500" type="test:Company" maxOccurs="500"/>

</xs:schema>

Ed Merks wrote:

> James,

> All the components of the schema mentioned in the redefine are incorporated
(i.e.,
> cloned) and the redefinitions are pervasively applied to all the components
in that
> clone. Note that if the schema being redefined has a null target namespace,
it may
> be redefined in multiple schemas each with a different namespace and each
in a
> different way; in this case, during incorporation, the namespace of the
clone is
> modified to match the namespace of the redefining schema and the other
redefinition
> modifications are applied as well. In any event, the original schema remains
> untouched so that it can and will be reused in its pristine form when
referenced
> directly.

> James Taylor wrote:

> > Ed,
> >
> > Thank you for the explanation. It's not clear to me how "pervasive" the
> > W3C spec
> > ( http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#modify-s chema) meant
> > a redefine to be when they state:
> >
> > The modifications have a pervasive impact, that is, only the redefined
> > components are used, even when referenced from other incorporated
> > components, whether redefined themselves or not.
> >
> > Given that later in the spec they imply that multiple redefines of the
> > same type that conflict are not legal, I assume they meant that the
> > redefined type should "pervade" everywhere, including in my example of
> > v4.xsd.
> >
> > James
> >
> > Ed Merks wrote:
> >
> > > James,
> >
> > > The v4.xsd schema isn't valid because its includes both a redefined
version
> > of
> > > personName and addressee, via its include of v2.xsd's redefinition of
> > v1.xsd, as
> > > well as the original version of personName and addressee, via its
include of
> > > v3.xsd's include of v1.xsd without redefinition. The v3.xsd schema
needs to
> > > include v2.xsd not v1.xsd for this example to be valid. The bottom line
is
> > that
> > > v1.xsd is not modified by virtue of the redefine in v2.xsd; only v2.xsd
sees
> > that
> > > redefinition directly and any schema importing or including v2.xsd will
see
> > that
> > > redefinition indirectly; but v3.xsd sees only the original v1.xsd and
knows
> > nothing
> > > of v2.xsd. When we get to v4.xsd, the result is name collision.
> >
> > > James Taylor wrote:
> >
> > > > Ed,
> > > >
> > > > Thanks for the reply. My sample is below. In v4.xsd, I would have
> > > > expected that the "marriedPeople" element would contain the
"generation"
> > > > element since it is redefined to include this in v2.xsd. The
> > > > "singlePeople" element does include the "generation" element as
expected.
> > > >
> > > > Thanks,
> > > >
> > > > James
> > > >
> > > > v1.xsd:
> > > > <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > <xs:complexType name="personName">
> > > > <xs:sequence>
> > > > <xs:element name="title" type="xs:string" minOccurs="0"/>
> > > > <xs:element name="forename" type="xs:string" minOccurs="0"
> > > > maxOccurs="unbounded"/>
> > > > </xs:sequence>
> > > > </xs:complexType>
> > > >
> > > > <xs:element name="addressee" type="test:personName"/>
> > > > </xs:schema>
> > > >
> > > > v2.xsd:
> > > > <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > <xs:redefine schemaLocation="v1.xsd">
> > > > <xs:complexType name="personName">
> > > > <xs:complexContent>
> > > > <xs:extension base="test:personName">
> > > > <xs:sequence>
> > > > <xs:element name="generation" type="xs:string" minOccurs="0"/>
> > > > </xs:sequence>
> > > > </xs:extension>
> > > > </xs:complexContent>
> > > > </xs:complexType>
> > > > </xs:redefine>
> > > >
> > > > <xs:element name="author" type="test:personName"/>
> > > > </xs:schema>
> > > >
> > > > v3.xsd:
> > > > <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > <xs:include schemaLocation="v1.xsd"/>
> > > >
> > > > <xs:complexType name="marriedPersonName">
> > > > <xs:complexContent>
> > > > <xs:extension base="test:personName">
> > > > <xs:sequence>
> > > > <xs:element name="maidenName" type="xs:string" minOccurs="0"/>
> > > > </xs:sequence>
> > > > </xs:extension>
> > > > </xs:complexContent>
> > > > </xs:complexType>
> > > >
> > > > <xs:element name="marriedPerson" type="test:marriedPersonName"/>
> > > >
> > > > </xs:schema>
> > > >
> > > > v4.xsd:
> > > > <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > <xs:include schemaLocation="v2.xsd"/>
> > > > <xs:include schemaLocation="v3.xsd"/>
> > > >
> > > > <xs:complexType name="people">
> > > > <xs:sequence>
> > > > <xs:element name="marriedPeople" type="test:marriedPersonName"
> > > > maxOccurs="unbounded"/>
> > > > <xs:element name="singlePeople" type="test:personName"
> > > > maxOccurs="unbounded"/>
> > > > </xs:sequence>
> > > > </xs:complexType>
> > > > <xs:element name="directory" type="test:people"/>
> > > > </xs:schema>
> > > >
> > > > Ed Merks wrote:
> > > >
> > > > > James,
> > > >
> > > > > I'm not sure I can really answer the details of your questions
without
> > clear
> > > > > references to particular components in actual schema documents,
i.e., a
> > > > > sample. Perhaps it helps to explain that redefinition is
accomplished by
> > > > > making a clone of the schema being redefined and then modifying that
copy
> > > > > according to the redefinition. The original schema is not touched;
it
> > may be
> > > > > redefined many times in many different ways. The schema containing
the
> > > > > redefine will see only the copy, not the original. Which version you
get
> > will
> > > > > depend very much on where you ask, so you need to be specific...
> > > >
> > > > > James Taylor wrote:
> > > >
> > > > > > Hello,
> > > > > > If I understand the W3C spec correctly, a redefined complexType
should
> > be
> > > > > > used everywhere in place of the original type. For example, if I
use
> > the
> > > > > > redefined complexType as a base type for another type, the derived
type
> > > > > > should now include the additional elements introduced by the
redefined
> > > > > > type. This is not the behavior I'm seeing in Eclipse XSD. When I
get
> > the
> > > > > > base type, using complexTypeDefinition.getBaseType(), I continue
to get
> > > > > > the original definition instead of the redefined one. References
to
> > the
> > > > > > type within the schema that has the redefine do point to the new
> > redefined
> > > > > > type, though. Is this intentional? Should I use a different
> > mechanism to
> > > > > > get the base type? Or is this a bug?
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > James
Re: redefine [message #39976 is a reply to message #39904] Fri, 26 March 2004 18:27
 Eclipse User
Originally posted by: merks.ca.ibm.com

--------------CEEB91C322B38F5CBD2D5836
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

James,

As I was fixing the Company.xsd to make it valid:

<xs:schema targetNamespace="http://namespaces.nextance.com/test"
xmlns:test="http://namespaces.nextance.com/test"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="unqualified" attributeFormDefault="unqualified">

<xs:redefine schemaLocation="Department.xsd">
<xs:complexType name="Employee">
<xs:complexContent>
<xs:extension base="test:Employee">
<xs:sequence>
<xs:element name="ranking" type="xs:int"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:redefine>

<xs:complexType name="Company">
<xs:sequence>
<xs:element name="department" type="test:Department"
maxOccurs="unbounded"/>
<xs:element name="president" type="test:Employee"/>
</xs:sequence>
</xs:complexType>

<xs:element name="fortune500" type="test:Company"/>

</xs:schema>

I discovered that there is a bug that causes the transitive includes/redefines of a
cloned included/redefined schema to be omitted so I opened
https://bugs.eclipse.org/bugs/show_bug.cgi?id=56328 and have fixed that particular
problem. So, to my way of thinking, the above sample is the correct way to express
what you intended.

Consider the following slightly modified example where Employee.xsd has no
namespace:

<xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="unqualified" attributeFormDefault="unqualified">
<xs:complexType name="Employee">
<xs:sequence>
<xs:element name="name" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:schema>

and Department.xsd is still the same (but the include is changing the null
namespace of the included schema to match that of the including schema):

<xs:schema targetNamespace="http://namespaces.nextance.com/test"
xmlns:test="http://namespaces.nextance.com/test"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="unqualified" attributeFormDefault="unqualified">
<xs:include schemaLocation="Employee.xsd"/>

<xs:complexType name="Department">
<xs:sequence>
<xs:element name="employee" type="test:Employee"
maxOccurs="unbounded"/>
<xs:element name="manager" type="test:Employee"/>
</xs:sequence>
</xs:complexType>
</xs:schema>

In this case, a Company.xsd can validly access both the original version of
Employee as well as a redefined version.

<xs:schema targetNamespace="http://namespaces.nextance.com/test"
xmlns:test="http://namespaces.nextance.com/test"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="unqualified" attributeFormDefault="unqualified">

<xs:import schemaLocation="Employee.xsd"/>

<xs:redefine schemaLocation="Department.xsd">
<xs:complexType name="Employee">
<xs:complexContent>
<xs:extension base="test:Employee">
<xs:sequence>
<xs:element name="ranking" type="xs:int"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:redefine>

<xs:complexType name="Company">
<xs:sequence>
<xs:element name="department" type="test:Department"
maxOccurs="unbounded"/>
<xs:element name="president" type="test:Employee"/>
<xs:element name="dummy" type="Employee"/>
</xs:sequence>
</xs:complexType>

<xs:element name="fortune500" type="test:Company"/>

</xs:schema>

The semantics view for this shows that everyone is using the redefined type, except
the junk element, which is using the original:

[Image]

This stuff is all really much too complicated for human minds to handle (and I
think there are still lurking bugs in the implementation, but I don't have any more
time to spend to look at this further).

James Taylor wrote:

> Ed,
>
> Here's a smaller more realistic example that illustrates an issue:
>
> File A defines Employee type
> File B includes File A and defines Department type
> File C includes File B, redefines Employee from File A and defines Company
> type
>
> This is a common use case for redefine in which a type in a nested include
> needs to be redefined. With Eclipse XSD, the redefine does not affect the
> Employee type within the Department type and affects the Employee type
> within the Company type only if the include of File B precedes the
> redefine of File A. This does not seem like the correct behavior.
>
> I've included the XSD files below. Thanks,
>
> James
>
> Employee.xsd:
> <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> xmlns:test="http://namespaces.nextance.com/test"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="unqualified" attributeFormDefault="unqualified">
> <xs:complexType name="Employee">
> <xs:sequence>
> <xs:element name="name" type="xs:string"/>
> </xs:sequence>
> </xs:complexType>
> </xs:schema>
>
> Department.xsd:
> <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> xmlns:test="http://namespaces.nextance.com/test"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="unqualified" attributeFormDefault="unqualified">
> <xs:include schemaLocation="Employee.xsd"/>
>
> <xs:complexType name="Department">
> <xs:sequence>
> <xs:element name="employee" type="test:Employee"
> maxOccurs="unbounded"/>
> <xs:element name="manager" type="test:Employee"/>
> </xs:sequence>
> </xs:complexType>
> </xs:schema>
>
> Company.xsd:
> <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> xmlns:test="http://namespaces.nextance.com/test"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="unqualified" attributeFormDefault="unqualified">
>
> <xs:include schemaLocation="Department.xsd"/>
>
> <xs:redefine schemaLocation="Employee.xsd">
> <xs:complexType name="Employee">
> <xs:complexContent>
> <xs:extension base="test:Employee">
> <xs:sequence>
> <xs:element name="ranking" type="xs:int"/>
> </xs:sequence>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
> </xs:redefine>
>
> <xs:complexType name="Company">
> <xs:sequence>
> <xs:element name="department" type="test:Department"
> maxOccurs="unbounded"/>
> <xs:element name="president" type="test:Employee"/>
> </xs:sequence>
> </xs:complexType>
>
> <xs:element name="fortune500" type="test:Company" maxOccurs="500"/>
>
> </xs:schema>
>
> Ed Merks wrote:
>
> > James,
>
> > All the components of the schema mentioned in the redefine are incorporated
> (i.e.,
> > cloned) and the redefinitions are pervasively applied to all the components
> in that
> > clone. Note that if the schema being redefined has a null target namespace,
> it may
> > be redefined in multiple schemas each with a different namespace and each
> in a
> > different way; in this case, during incorporation, the namespace of the
> clone is
> > modified to match the namespace of the redefining schema and the other
> redefinition
> > modifications are applied as well. In any event, the original schema remains
> > untouched so that it can and will be reused in its pristine form when
> referenced
> > directly.
>
> > James Taylor wrote:
>
> > > Ed,
> > >
> > > Thank you for the explanation. It's not clear to me how "pervasive" the
> > > W3C spec
> > > ( http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#modify-s chema) meant
> > > a redefine to be when they state:
> > >
> > > The modifications have a pervasive impact, that is, only the redefined
> > > components are used, even when referenced from other incorporated
> > > components, whether redefined themselves or not.
> > >
> > > Given that later in the spec they imply that multiple redefines of the
> > > same type that conflict are not legal, I assume they meant that the
> > > redefined type should "pervade" everywhere, including in my example of
> > > v4.xsd.
> > >
> > > James
> > >
> > > Ed Merks wrote:
> > >
> > > > James,
> > >
> > > > The v4.xsd schema isn't valid because its includes both a redefined
> version
> > > of
> > > > personName and addressee, via its include of v2.xsd's redefinition of
> > > v1.xsd, as
> > > > well as the original version of personName and addressee, via its
> include of
> > > > v3.xsd's include of v1.xsd without redefinition. The v3.xsd schema
> needs to
> > > > include v2.xsd not v1.xsd for this example to be valid. The bottom line
> is
> > > that
> > > > v1.xsd is not modified by virtue of the redefine in v2.xsd; only v2.xsd
> sees
> > > that
> > > > redefinition directly and any schema importing or including v2.xsd will
> see
> > > that
> > > > redefinition indirectly; but v3.xsd sees only the original v1.xsd and
> knows
> > > nothing
> > > > of v2.xsd. When we get to v4.xsd, the result is name collision.
> > >
> > > > James Taylor wrote:
> > >
> > > > > Ed,
> > > > >
> > > > > Thanks for the reply. My sample is below. In v4.xsd, I would have
> > > > > expected that the "marriedPeople" element would contain the
> "generation"
> > > > > element since it is redefined to include this in v2.xsd. The
> > > > > "singlePeople" element does include the "generation" element as
> expected.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > James
> > > > >
> > > > > v1.xsd:
> > > > > <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > > <xs:complexType name="personName">
> > > > > <xs:sequence>
> > > > > <xs:element name="title" type="xs:string" minOccurs="0"/>
> > > > > <xs:element name="forename" type="xs:string" minOccurs="0"
> > > > > maxOccurs="unbounded"/>
> > > > > </xs:sequence>
> > > > > </xs:complexType>
> > > > >
> > > > > <xs:element name="addressee" type="test:personName"/>
> > > > > </xs:schema>
> > > > >
> > > > > v2.xsd:
> > > > > <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > > <xs:redefine schemaLocation="v1.xsd">
> > > > > <xs:complexType name="personName">
> > > > > <xs:complexContent>
> > > > > <xs:extension base="test:personName">
> > > > > <xs:sequence>
> > > > > <xs:element name="generation" type="xs:string" minOccurs="0"/>
> > > > > </xs:sequence>
> > > > > </xs:extension>
> > > > > </xs:complexContent>
> > > > > </xs:complexType>
> > > > > </xs:redefine>
> > > > >
> > > > > <xs:element name="author" type="test:personName"/>
> > > > > </xs:schema>
> > > > >
> > > > > v3.xsd:
> > > > > <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > > <xs:include schemaLocation="v1.xsd"/>
> > > > >
> > > > > <xs:complexType name="marriedPersonName">
> > > > > <xs:complexContent>
> > > > > <xs:extension base="test:personName">
> > > > > <xs:sequence>
> > > > > <xs:element name="maidenName" type="xs:string" minOccurs="0"/>
> > > > > </xs:sequence>
> > > > > </xs:extension>
> > > > > </xs:complexContent>
> > > > > </xs:complexType>
> > > > >
> > > > > <xs:element name="marriedPerson" type="test:marriedPersonName"/>
> > > > >
> > > > > </xs:schema>
> > > > >
> > > > > v4.xsd:
> > > > > <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > > <xs:include schemaLocation="v2.xsd"/>
> > > > > <xs:include schemaLocation="v3.xsd"/>
> > > > >
> > > > > <xs:complexType name="people">
> > > > > <xs:sequence>
> > > > > <xs:element name="marriedPeople" type="test:marriedPersonName"
> > > > > maxOccurs="unbounded"/>
> > > > > <xs:element name="singlePeople" type="test:personName"
> > > > > maxOccurs="unbounded"/>
> > > > > </xs:sequence>
> > > > > </xs:complexType>
> > > > > <xs:element name="directory" type="test:people"/>
> > > > > </xs:schema>
> > > > >
> > > > > Ed Merks wrote:
> > > > >
> > > > > > James,
> > > > >
> > > > > > I'm not sure I can really answer the details of your questions
> without
> > > clear
> > > > > > references to particular components in actual schema documents,
> i.e., a
> > > > > > sample. Perhaps it helps to explain that redefinition is
> accomplished by
> > > > > > making a clone of the schema being redefined and then modifying that
> copy
> > > > > > according to the redefinition. The original schema is not touched;
> it
> > > may be
> > > > > > redefined many times in many different ways. The schema containing
> the
> > > > > > redefine will see only the copy, not the original. Which version you
> get
> > > will
> > > > > > depend very much on where you ask, so you need to be specific...
> > > > >
> > > > > > James Taylor wrote:
> > > > >
> > > > > > > Hello,
> > > > > > > If I understand the W3C spec correctly, a redefined complexType
> should
> > > be
> > > > > > > used everywhere in place of the original type. For example, if I
> use
> > > the
> > > > > > > redefined complexType as a base type for another type, the derived
> type
> > > > > > > should now include the additional elements introduced by the
> redefined
> > > > > > > type. This is not the behavior I'm seeing in Eclipse XSD. When I
> get
> > > the
> > > > > > > base type, using complexTypeDefinition.getBaseType(), I continue
> to get
> > > > > > > the original definition instead of the redefined one. References
> to
> > > the
> > > > > > > type within the schema that has the redefine do point to the new
> > > redefined
> > > > > > > type, though. Is this intentional? Should I use a different
> > > mechanism to
> > > > > > > get the base type? Or is this a bug?
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > James

--------------CEEB91C322B38F5CBD2D5836
Content-Type: multipart/related;
boundary="------------57AEC190E1D3D8E73CCE5127"

--------------57AEC190E1D3D8E73CCE5127
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
James,
<p>As I was fixing the Company.xsd to make it valid:
<blockquote><font size=-1>&lt;xs:schema targetNamespace="<A HREF="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</A>"</font>
<br><font size=-1>xmlns:test="<A HREF="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</A>"</font>
<br><font size=-1>xmlns:xs="<A HREF="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</A>"</font>
<br><font size=-1>elementFormDefault="unqualified" attributeFormDefault="unqualified"></font><font size=-1></font>
<p><font size=-1>&nbsp; &lt;xs:redefine schemaLocation="Department.xsd"></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp; &lt;xs:complexType name="Employee"></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:complexContent></font>
<br><font size=-1> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;xs:extension
base="test:Employee"></font>
<br><font size=-1> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
&lt;xs:sequence></font>
<br><font size=-1> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xs:element name="ranking" type="xs:int"/></font>
<br><font size=-1> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
&lt;/xs:sequence></font>
<br><font size=-1> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;/xs:extension></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:complexContent></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp; &lt;/xs:complexType></font>
<br><font size=-1>&nbsp; &lt;/xs:redefine></font><font size=-1></font>
<p><font size=-1>&nbsp; &lt;xs:complexType name="Company"></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp; &lt;xs:sequence></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="department"
type="test:Department" maxOccurs="unbounded"/></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="president"
type="test:Employee"/></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp; &lt;/xs:sequence></font>
<br><font size=-1>&nbsp; &lt;/xs:complexType></font><font size=-1></font>
<p><font size=-1>&nbsp; &lt;xs:element name="fortune500" type="test:Company"/></font><font size=-1></font>
<p><font size=-1>&lt;/xs:schema></font></blockquote>
I discovered that there is a bug that causes the transitive includes/redefines
of a cloned included/redefined schema to be omitted so I opened&nbsp; <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=56328">https://bugs.eclipse.org/bugs/show_bug.cgi?id=56328</a>
and have fixed that particular problem. So, to my way of thinking, the
above sample is the correct way to express what you intended.
<p>Consider the following slightly modified example where Employee.xsd
has no namespace:
<blockquote><font size=-1>&lt;xs:schema</font>
<br><font size=-1>xmlns:xs="<A HREF="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</A>"</font>
<br><font size=-1>elementFormDefault="unqualified" attributeFormDefault="unqualified"></font>
<br><font size=-1>&nbsp; &lt;xs:complexType name="Employee"></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp; &lt;xs:sequence></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="name"
type="xs:string"/></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp; &lt;/xs:sequence></font>
<br><font size=-1>&nbsp; &lt;/xs:complexType></font>
<br><font size=-1>&lt;/xs:schema></font></blockquote>
and Department.xsd is still the same (but the include is changing the null
namespace of the included schema to match that of the including schema):
<blockquote><font size=-1>&lt;xs:schema targetNamespace="<A HREF="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</A>"</font>
<br><font size=-1>xmlns:test="<A HREF="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</A>"</font>
<br><font size=-1>xmlns:xs="<A HREF="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</A>"</font>
<br><font size=-1>elementFormDefault="unqualified" attributeFormDefault="unqualified"></font>
<br><font size=-1>&nbsp; &lt;xs:include schemaLocation="Employee.xsd"/></font><font size=-1></font>
<p><font size=-1>&nbsp; &lt;xs:complexType name="Department"></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp; &lt;xs:sequence></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="employee"
type="test:Employee" maxOccurs="unbounded"/></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="manager"
type="test:Employee"/></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp; &lt;/xs:sequence></font>
<br><font size=-1>&nbsp; &lt;/xs:complexType></font>
<br><font size=-1>&lt;/xs:schema></font></blockquote>
In this case, a Company.xsd can validly access both the original version
of Employee as well as a redefined version.
<blockquote><font size=-1>&lt;xs:schema targetNamespace="<A HREF="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</A>"</font>
<br><font size=-1>xmlns:test="<A HREF="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</A>"</font>
<br><font size=-1>xmlns:xs="<A HREF="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</A>"</font>
<br><font size=-1>elementFormDefault="unqualified" attributeFormDefault="unqualified"></font><font size=-1></font>
<p><font size=-1>&nbsp; &lt;xs:import schemaLocation="Employee.xsd"/></font><font size=-1></font>
<p><font size=-1>&nbsp; &lt;xs:redefine schemaLocation="Department.xsd"></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp; &lt;xs:complexType name="Employee"></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:complexContent></font>
<br><font size=-1> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;xs:extension
base="test:Employee"></font>
<br><font size=-1> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
&lt;xs:sequence></font>
<br><font size=-1> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xs:element name="ranking" type="xs:int"/></font>
<br><font size=-1> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
&lt;/xs:sequence></font>
<br><font size=-1> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;/xs:extension></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:complexContent></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp; &lt;/xs:complexType></font>
<br><font size=-1>&nbsp; &lt;/xs:redefine></font><font size=-1></font>
<p><font size=-1>&nbsp; &lt;xs:complexType name="Company"></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp; &lt;xs:sequence></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="department"
type="test:Department" maxOccurs="unbounded"/></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="president"
type="test:Employee"/></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="dummy"
type="Employee"/></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp; &lt;/xs:sequence></font>
<br><font size=-1>&nbsp; &lt;/xs:complexType></font><font size=-1></font>
<p><font size=-1>&nbsp; &lt;xs:element name="fortune500" type="test:Company"/></font><font size=-1></font>
<p><font size=-1>&lt;/xs:schema></font></blockquote>
The semantics view for this shows that everyone is using the redefined
type, except the junk element, which is using the original:
<blockquote><img SRC="cid:part1.40647602.566D4349@ca.ibm.com" height=771 width=263></blockquote>
This stuff is all really much too complicated for human minds to handle
(and I think there are still lurking bugs in the implementation, but I
don't have any more time to spend to look at this further).
<br>&nbsp;
<p>James Taylor wrote:
<blockquote TYPE=CITE>Ed,
<p>Here's a smaller more realistic example that illustrates an issue:
<p>File A defines Employee type
<br>File B includes File A and defines Department type
<br>File C includes File B, redefines Employee from File A and defines
Company
<br>type
<p>This is a common use case for redefine in which a type in a nested include
<br>needs to be redefined.&nbsp; With Eclipse XSD, the redefine does not
affect the
<br>Employee type within the Department type and affects the Employee type
<br>within the Company type only if the include of File B precedes the
<br>redefine of File A.&nbsp; This does not seem like the correct behavior.
<p>I've included the XSD files below.&nbsp; Thanks,
<p>&nbsp;&nbsp;&nbsp; James
<p>Employee.xsd:
<br>&lt;xs:schema targetNamespace="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>xmlns:test="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>xmlns:xs="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>elementFormDefault="unqualified" attributeFormDefault="unqualified">
<br>&nbsp; &lt;xs:complexType name="Employee">
<br>&nbsp;&nbsp;&nbsp; &lt;xs:sequence>
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="name" type="xs:string"/>
<br>&nbsp;&nbsp;&nbsp; &lt;/xs:sequence>
<br>&nbsp; &lt;/xs:complexType>
<br>&lt;/xs:schema>
<p>Department.xsd:
<br>&lt;xs:schema targetNamespace="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>xmlns:test="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>xmlns:xs="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>elementFormDefault="unqualified" attributeFormDefault="unqualified">
<br>&nbsp; &lt;xs:include schemaLocation="Employee.xsd"/>
<p>&nbsp; &lt;xs:complexType name="Department">
<br>&nbsp;&nbsp;&nbsp; &lt;xs:sequence>
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="employee" type="test:Employee"
<br>maxOccurs="unbounded"/>
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="manager" type="test:Employee"/>
<br>&nbsp;&nbsp;&nbsp; &lt;/xs:sequence>
<br>&nbsp; &lt;/xs:complexType>
<br>&lt;/xs:schema>
<p>Company.xsd:
<br>&lt;xs:schema targetNamespace="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>xmlns:test="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>xmlns:xs="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>elementFormDefault="unqualified" attributeFormDefault="unqualified">
<p>&nbsp; &lt;xs:include schemaLocation="Department.xsd"/>
<p>&nbsp; &lt;xs:redefine schemaLocation="Employee.xsd">
<br>&nbsp;&nbsp;&nbsp; &lt;xs:complexType name="Employee">
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:complexContent>
<br> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;xs:extension base="test:Employee">
<br> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &lt;xs:sequence>
<br> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xs:element name="ranking" type="xs:int"/>
<br> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &lt;/xs:sequence>
<br> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;/xs:extension>
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:complexContent>
<br>&nbsp;&nbsp;&nbsp; &lt;/xs:complexType>
<br>&nbsp; &lt;/xs:redefine>
<p>&nbsp; &lt;xs:complexType name="Company">
<br>&nbsp;&nbsp;&nbsp; &lt;xs:sequence>
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="department" type="test:Department"
<br>maxOccurs="unbounded"/>
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="president" type="test:Employee"/>
<br>&nbsp;&nbsp;&nbsp; &lt;/xs:sequence>
<br>&nbsp; &lt;/xs:complexType>
<p>&nbsp; &lt;xs:element name="fortune500" type="test:Company" maxOccurs="500"/>
<p>&lt;/xs:schema>
<p>Ed Merks wrote:
<p>> James,
<p>> All the components of the schema mentioned in the redefine are incorporated
<br>(i.e.,
<br>> cloned) and the redefinitions are pervasively applied to all the
components
<br>in that
<br>> clone.&nbsp; Note that if the schema being redefined has a null target
namespace,
<br>it may
<br>> be redefined in&nbsp; multiple schemas each with a different namespace
and each
<br>in a
<br>> different way; in this case, during incorporation, the namespace
of the
<br>clone is
<br>> modified to match the namespace of the redefining schema and the
other
<br>redefinition
<br>> modifications are applied as well.&nbsp; In any event, the original
schema remains
<br>> untouched so that it can and will be reused in its pristine form
when
<br>referenced
<br>> directly.
<p>> James Taylor wrote:
<p>> > Ed,
<br>> >
<br>> > Thank you for the explanation.&nbsp; It's not clear to me how "pervasive"
the
<br>> > W3C spec
<br>> > (<a href=" http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#modify-s chema"> http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#modify-s chema</a>)
meant
<br>> > a redefine to be when they state:
<br>> >
<br>> >&nbsp;&nbsp;&nbsp;&nbsp; The modifications have a pervasive impact,
that is, only the redefined
<br>> >&nbsp;&nbsp;&nbsp;&nbsp; components are used, even when referenced
from other incorporated
<br>> >&nbsp;&nbsp;&nbsp;&nbsp; components, whether redefined themselves
or not.
<br>> >
<br>> > Given that later in the spec they imply that multiple redefines
of the
<br>> > same type that conflict are not legal, I assume they meant that
the
<br>> > redefined type should "pervade" everywhere, including in my example
of
<br>> > v4.xsd.
<br>> >
<br>> >&nbsp;&nbsp;&nbsp;&nbsp; James
<br>> >
<br>> > Ed Merks wrote:
<br>> >
<br>> > > James,
<br>> >
<br>> > > The v4.xsd schema isn't valid because its includes both a redefined
<br>version
<br>> > of
<br>> > > personName and addressee, via its include of v2.xsd's redefinition
of
<br>> > v1.xsd, as
<br>> > > well as the original version of personName and addressee, via
its
<br>include of
<br>> > > v3.xsd's include of v1.xsd without redefinition.&nbsp; The v3.xsd
schema
<br>needs to
<br>> > > include v2.xsd not v1.xsd for this example to be valid.&nbsp;
The bottom line
<br>is
<br>> > that
<br>> > > v1.xsd is not modified by virtue of the redefine in v2.xsd; only
v2.xsd
<br>sees
<br>> > that
<br>> > > redefinition directly and any schema importing or including v2.xsd
will
<br>see
<br>> > that
<br>> > > redefinition indirectly; but v3.xsd sees only the original v1.xsd
and
<br>knows
<br>> > nothing
<br>> > > of v2.xsd.&nbsp; When we get to v4.xsd, the result is name collision.
<br>> >
<br>> > > James Taylor wrote:
<br>> >
<br>> > > > Ed,
<br>> > > >
<br>> > > > Thanks for the reply.&nbsp; My sample is below.&nbsp; In v4.xsd,
I would have
<br>> > > > expected that the "marriedPeople" element would contain the
<br>"generation"
<br>> > > > element since it is redefined to include this in v2.xsd.&nbsp;
The
<br>> > > > "singlePeople" element does include the "generation" element
as
<br>expected.
<br>> > > >
<br>> > > > Thanks,
<br>> > > >
<br>> > > >&nbsp;&nbsp;&nbsp;&nbsp; James
<br>> > > >
<br>> > > > v1.xsd:
<br>> > > > &lt;xs:schema targetNamespace="<a href="http://namespaces.nextance.com/nex/test">http://namespaces.nextance.com/nex/test</a>"
<br>> > > > xmlns:test="<a href="http://namespaces.nextance.com/nex/test">http://namespaces.nextance.com/nex/test</a>"
<br>> > > > xmlns:xs="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
<br>> > > >&nbsp; &lt;xs:complexType name="personName">
<br>> > > >&nbsp;&nbsp; &lt;xs:sequence>
<br>> > > >&nbsp;&nbsp;&nbsp; &lt;xs:element name="title" type="xs:string"
minOccurs="0"/>
<br>> > > >&nbsp;&nbsp;&nbsp; &lt;xs:element name="forename" type="xs:string"
minOccurs="0"
<br>> > > > maxOccurs="unbounded"/>
<br>> > > >&nbsp;&nbsp; &lt;/xs:sequence>
<br>> > > >&nbsp; &lt;/xs:complexType>
<br>> > > >
<br>> > > >&nbsp; &lt;xs:element name="addressee" type="test:personName"/>
<br>> > > > &lt;/xs:schema>
<br>> > > >
<br>> > > > v2.xsd:
<br>> > > > &lt;xs:schema targetNamespace="<a href="http://namespaces.nextance.com/nex/test">http://namespaces.nextance.com/nex/test</a>"
<br>> > > > xmlns:test="<a href="http://namespaces.nextance.com/nex/test">http://namespaces.nextance.com/nex/test</a>"
<br>> > > > xmlns:xs="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
<br>> > > >&nbsp; &lt;xs:redefine schemaLocation="v1.xsd">
<br>> > > >&nbsp;&nbsp; &lt;xs:complexType name="personName">
<br>> > > >&nbsp;&nbsp;&nbsp; &lt;xs:complexContent>
<br>> > > >&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:extension base="test:personName">
<br>> > > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:sequence>
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="generation"
type="xs:string" minOccurs="0"/>
<br>> > > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:sequence>
<br>> > > >&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:extension>
<br>> > > >&nbsp;&nbsp;&nbsp; &lt;/xs:complexContent>
<br>> > > >&nbsp;&nbsp; &lt;/xs:complexType>
<br>> > > >&nbsp; &lt;/xs:redefine>
<br>> > > >
<br>> > > >&nbsp; &lt;xs:element name="author" type="test:personName"/>
<br>> > > > &lt;/xs:schema>
<br>> > > >
<br>> > > > v3.xsd:
<br>> > > > &lt;xs:schema targetNamespace="<a href="http://namespaces.nextance.com/nex/test">http://namespaces.nextance.com/nex/test</a>"
<br>> > > > xmlns:test="<a href="http://namespaces.nextance.com/nex/test">http://namespaces.nextance.com/nex/test</a>"
<br>> > > > xmlns:xs="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
<br>> > > >&nbsp; &lt;xs:include schemaLocation="v1.xsd"/>
<br>> > > >
<br>> > > >&nbsp;&nbsp; &lt;xs:complexType name="marriedPersonName">
<br>> > > >&nbsp;&nbsp;&nbsp; &lt;xs:complexContent>
<br>> > > >&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:extension base="test:personName">
<br>> > > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:sequence>
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="maidenName"
type="xs:string" minOccurs="0"/>
<br>> > > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:sequence>
<br>> > > >&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:extension>
<br>> > > >&nbsp;&nbsp;&nbsp; &lt;/xs:complexContent>
<br>> > > >&nbsp;&nbsp; &lt;/xs:complexType>
<br>> > > >
<br>> > > >&nbsp; &lt;xs:element name="marriedPerson" type="test:marriedPersonName"/>
<br>> > > >
<br>> > > > &lt;/xs:schema>
<br>> > > >
<br>> > > > v4.xsd:
<br>> > > > &lt;xs:schema targetNamespace="<a href="http://namespaces.nextance.com/nex/test">http://namespaces.nextance.com/nex/test</a>"
<br>> > > > xmlns:test="<a href="http://namespaces.nextance.com/nex/test">http://namespaces.nextance.com/nex/test</a>"
<br>> > > > xmlns:xs="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
<br>> > > >&nbsp; &lt;xs:include schemaLocation="v2.xsd"/>
<br>> > > >&nbsp; &lt;xs:include schemaLocation="v3.xsd"/>
<br>> > > >
<br>> > > >&nbsp;&nbsp; &lt;xs:complexType name="people">
<br>> > > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:sequence>
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="marriedPeople"
type="test:marriedPersonName"
<br>> > > > maxOccurs="unbounded"/>
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="singlePeople"
type="test:personName"
<br>> > > > maxOccurs="unbounded"/>
<br>> > > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:sequence>
<br>> > > >&nbsp;&nbsp; &lt;/xs:complexType>
<br>> > > >&nbsp; &lt;xs:element name="directory" type="test:people"/>
<br>> > > > &lt;/xs:schema>
<br>> > > >
<br>> > > > Ed Merks wrote:
<br>> > > >
<br>> > > > > James,
<br>> > > >
<br>> > > > > I'm not sure I can really answer the details of your questions
<br>without
<br>> > clear
<br>> > > > > references to particular components in actual schema documents,
<br>i.e., a
<br>> > > > > sample.&nbsp; Perhaps it helps to explain that redefinition
is
<br>accomplished by
<br>> > > > > making a clone of the schema being redefined and then modifying
that
<br>copy
<br>> > > > > according to the redefinition.&nbsp; The original schema
is not touched;
<br>it
<br>> > may be
<br>> > > > > redefined many times in many different ways. The schema containing
<br>the
<br>> > > > > redefine will see only the copy, not the original. Which
version you
<br>get
<br>> > will
<br>> > > > > depend very much on where you ask, so you need to be specific...
<br>> > > >
<br>> > > > > James Taylor wrote:
<br>> > > >
<br>> > > > > > Hello,
<br>> > > > > > If I understand the W3C spec correctly, a redefined complexType
<br>should
<br>> > be
<br>> > > > > > used everywhere in place of the original type.&nbsp; For
example, if I
<br>use
<br>> > the
<br>> > > > > > redefined complexType as a base type for another type,
the derived
<br>type
<br>> > > > > > should now include the additional elements introduced by
the
<br>redefined
<br>> > > > > > type.&nbsp; This is not the behavior I'm seeing in Eclipse
XSD.&nbsp; When I
<br>get
<br>> > the
<br>> > > > > > base type, using complexTypeDefinition.getBaseType(), I
continue
<br>to get
<br>> > > > > > the original definition instead of the redefined one.&nbsp;
References
<br>to
<br>> > the
<br>> > > > > > type within the schema that has the redefine do point to
the new
<br>> > redefined
<br>> > > > > > type, though.&nbsp; Is this intentional?&nbsp; Should I
use a different
<br>> > mechanism to
<br>> > > > > > get the base type?&nbsp; Or is this a bug?
<br>> > > > > >
<br>> > > > > > Thanks,
<br>> > > > > >
<br>> > > > > >&nbsp;&nbsp;&nbsp;&nbsp; James</blockquote>
</html>

--------------57AEC190E1D3D8E73CCE5127
Content-Type: image/jpeg
Content-ID: <part1.40647602.566D4349@ca.ibm.com>
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\nsmailC1.jpeg"

/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDACAWGBwYFCAcGhwkIiAmMFA0MCws MGJGSjpQdGZ6
eHJmcG6AkLicgIiuim5woNqirr7EztDOfJri8uDI8LjKzsb/2wBDASIkJDAq MF40NF7GhHCE
xsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbG xsbGxsb/wAAR
CAMDAQcDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcI CQoL/8QAtRAA
AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhB
Re: redefine [message #40038 is a reply to message #39976] Mon, 29 March 2004 22:56
 Eclipse User
Originally posted by: jtaylor.nextance.com

Ed,

Thanks for fixing the bug you found and sorry about the error in
Company.xsd. I sent a question to the W3C regarding redefines because I
don't think the spec is as clear as it could be, and the answers I
received clarify things:

http://lists.w3.org/Archives/Public/xmlschema-dev/2004Mar/00 54.html

I understand the revised example you've shown below is an alternative,
however, it still should work the way I expressed it. The reason this is
an important issue for us here at my company is that our schemas can
become large with many levels of nesting. Being forced to redefine every
encompassing type for all occurrences of a type becomes cumbersome and
potentially error prone if an occurrence is missed. It can also prevents
being able to redefine a type nested inside of element declaration with an
anonymous type.

I'll volunteer to fix it if that helps.

James

Ed Merks wrote:
> James,

> As I was fixing the Company.xsd to make it valid:

> <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> xmlns:test="http://namespaces.nextance.com/test"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="unqualified" attributeFormDefault="unqualified">

> <xs:redefine schemaLocation="Department.xsd">
> <xs:complexType name="Employee">
> <xs:complexContent>
> <xs:extension base="test:Employee">
> <xs:sequence>
> <xs:element name="ranking" type="xs:int"/>
> </xs:sequence>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
> </xs:redefine>

> <xs:complexType name="Company">
> <xs:sequence>
> <xs:element name="department" type="test:Department"
> maxOccurs="unbounded"/>
> <xs:element name="president" type="test:Employee"/>
> </xs:sequence>
> </xs:complexType>

> <xs:element name="fortune500" type="test:Company"/>

> </xs:schema>

> I discovered that there is a bug that causes the transitive
includes/redefines of a
> cloned included/redefined schema to be omitted so I opened
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=56328 and have fixed that
particular
> problem. So, to my way of thinking, the above sample is the correct way to
express
> what you intended.

> Consider the following slightly modified example where Employee.xsd has no
> namespace:

> <xs:schema
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="unqualified" attributeFormDefault="unqualified">
> <xs:complexType name="Employee">
> <xs:sequence>
> <xs:element name="name" type="xs:string"/>
> </xs:sequence>
> </xs:complexType>
> </xs:schema>

> and Department.xsd is still the same (but the include is changing the null
> namespace of the included schema to match that of the including schema):

> <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> xmlns:test="http://namespaces.nextance.com/test"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="unqualified" attributeFormDefault="unqualified">
> <xs:include schemaLocation="Employee.xsd"/>

> <xs:complexType name="Department">
> <xs:sequence>
> <xs:element name="employee" type="test:Employee"
> maxOccurs="unbounded"/>
> <xs:element name="manager" type="test:Employee"/>
> </xs:sequence>
> </xs:complexType>
> </xs:schema>

> In this case, a Company.xsd can validly access both the original version of
> Employee as well as a redefined version.

> <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> xmlns:test="http://namespaces.nextance.com/test"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="unqualified" attributeFormDefault="unqualified">

> <xs:import schemaLocation="Employee.xsd"/>

> <xs:redefine schemaLocation="Department.xsd">
> <xs:complexType name="Employee">
> <xs:complexContent>
> <xs:extension base="test:Employee">
> <xs:sequence>
> <xs:element name="ranking" type="xs:int"/>
> </xs:sequence>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
> </xs:redefine>

> <xs:complexType name="Company">
> <xs:sequence>
> <xs:element name="department" type="test:Department"
> maxOccurs="unbounded"/>
> <xs:element name="president" type="test:Employee"/>
> <xs:element name="dummy" type="Employee"/>
> </xs:sequence>
> </xs:complexType>

> <xs:element name="fortune500" type="test:Company"/>

> </xs:schema>

> The semantics view for this shows that everyone is using the redefined type,
except
> the junk element, which is using the original:

> [Image]

> This stuff is all really much too complicated for human minds to handle (and
I
> think there are still lurking bugs in the implementation, but I don't have
any more
> time to spend to look at this further).

> James Taylor wrote:

> > Ed,
> >
> > Here's a smaller more realistic example that illustrates an issue:
> >
> > File A defines Employee type
> > File B includes File A and defines Department type
> > File C includes File B, redefines Employee from File A and defines Company
> > type
> >
> > This is a common use case for redefine in which a type in a nested include
> > needs to be redefined. With Eclipse XSD, the redefine does not affect the
> > Employee type within the Department type and affects the Employee type
> > within the Company type only if the include of File B precedes the
> > redefine of File A. This does not seem like the correct behavior.
> >
> > I've included the XSD files below. Thanks,
> >
> > James
> >
> > Employee.xsd:
> > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > xmlns:test="http://namespaces.nextance.com/test"
> > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > <xs:complexType name="Employee">
> > <xs:sequence>
> > <xs:element name="name" type="xs:string"/>
> > </xs:sequence>
> > </xs:complexType>
> > </xs:schema>
> >
> > Department.xsd:
> > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > xmlns:test="http://namespaces.nextance.com/test"
> > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > <xs:include schemaLocation="Employee.xsd"/>
> >
> > <xs:complexType name="Department">
> > <xs:sequence>
> > <xs:element name="employee" type="test:Employee"
> > maxOccurs="unbounded"/>
> > <xs:element name="manager" type="test:Employee"/>
> > </xs:sequence>
> > </xs:complexType>
> > </xs:schema>
> >
> > Company.xsd:
> > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > xmlns:test="http://namespaces.nextance.com/test"
> > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> >
> > <xs:include schemaLocation="Department.xsd"/>
> >
> > <xs:redefine schemaLocation="Employee.xsd">
> > <xs:complexType name="Employee">
> > <xs:complexContent>
> > <xs:extension base="test:Employee">
> > <xs:sequence>
> > <xs:element name="ranking" type="xs:int"/>
> > </xs:sequence>
> > </xs:extension>
> > </xs:complexContent>
> > </xs:complexType>
> > </xs:redefine>
> >
> > <xs:complexType name="Company">
> > <xs:sequence>
> > <xs:element name="department" type="test:Department"
> > maxOccurs="unbounded"/>
> > <xs:element name="president" type="test:Employee"/>
> > </xs:sequence>
> > </xs:complexType>
> >
> > <xs:element name="fortune500" type="test:Company" maxOccurs="500"/>
> >
> > </xs:schema>
> >
> > Ed Merks wrote:
> >
> > > James,
> >
> > > All the components of the schema mentioned in the redefine are
incorporated
> > (i.e.,
> > > cloned) and the redefinitions are pervasively applied to all the
components
> > in that
> > > clone. Note that if the schema being redefined has a null target
namespace,
> > it may
> > > be redefined in multiple schemas each with a different namespace and
each
> > in a
> > > different way; in this case, during incorporation, the namespace of the
> > clone is
> > > modified to match the namespace of the redefining schema and the other
> > redefinition
> > > modifications are applied as well. In any event, the original schema
remains
> > > untouched so that it can and will be reused in its pristine form when
> > referenced
> > > directly.
> >
> > > James Taylor wrote:
> >
> > > > Ed,
> > > >
> > > > Thank you for the explanation. It's not clear to me how "pervasive"
the
> > > > W3C spec
> > > > ( http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#modify-s chema)
meant
> > > > a redefine to be when they state:
> > > >
> > > > The modifications have a pervasive impact, that is, only the
redefined
> > > > components are used, even when referenced from other incorporated
> > > > components, whether redefined themselves or not.
> > > >
> > > > Given that later in the spec they imply that multiple redefines of the
> > > > same type that conflict are not legal, I assume they meant that the
> > > > redefined type should "pervade" everywhere, including in my example of
> > > > v4.xsd.
> > > >
> > > > James
> > > >
> > > > Ed Merks wrote:
> > > >
> > > > > James,
> > > >
> > > > > The v4.xsd schema isn't valid because its includes both a redefined
> > version
> > > > of
> > > > > personName and addressee, via its include of v2.xsd's redefinition of
> > > > v1.xsd, as
> > > > > well as the original version of personName and addressee, via its
> > include of
> > > > > v3.xsd's include of v1.xsd without redefinition. The v3.xsd schema
> > needs to
> > > > > include v2.xsd not v1.xsd for this example to be valid. The bottom
line
> > is
> > > > that
> > > > > v1.xsd is not modified by virtue of the redefine in v2.xsd; only
v2.xsd
> > sees
> > > > that
> > > > > redefinition directly and any schema importing or including v2.xsd
will
> > see
> > > > that
> > > > > redefinition indirectly; but v3.xsd sees only the original v1.xsd and
> > knows
> > > > nothing
> > > > > of v2.xsd. When we get to v4.xsd, the result is name collision.
> > > >
> > > > > James Taylor wrote:
> > > >
> > > > > > Ed,
> > > > > >
> > > > > > Thanks for the reply. My sample is below. In v4.xsd, I would have
> > > > > > expected that the "marriedPeople" element would contain the
> > "generation"
> > > > > > element since it is redefined to include this in v2.xsd. The
> > > > > > "singlePeople" element does include the "generation" element as
> > expected.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > James
> > > > > >
> > > > > > v1.xsd:
> > > > > > <xs:schema
targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > elementFormDefault="unqualified"
attributeFormDefault="unqualified">
> > > > > > <xs:complexType name="personName">
> > > > > > <xs:sequence>
> > > > > > <xs:element name="title" type="xs:string" minOccurs="0"/>
> > > > > > <xs:element name="forename" type="xs:string" minOccurs="0"
> > > > > > maxOccurs="unbounded"/>
> > > > > > </xs:sequence>
> > > > > > </xs:complexType>
> > > > > >
> > > > > > <xs:element name="addressee" type="test:personName"/>
> > > > > > </xs:schema>
> > > > > >
> > > > > > v2.xsd:
> > > > > > <xs:schema
targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > elementFormDefault="unqualified"
attributeFormDefault="unqualified">
> > > > > > <xs:redefine schemaLocation="v1.xsd">
> > > > > > <xs:complexType name="personName">
> > > > > > <xs:complexContent>
> > > > > > <xs:extension base="test:personName">
> > > > > > <xs:sequence>
> > > > > > <xs:element name="generation" type="xs:string"
minOccurs="0"/>
> > > > > > </xs:sequence>
> > > > > > </xs:extension>
> > > > > > </xs:complexContent>
> > > > > > </xs:complexType>
> > > > > > </xs:redefine>
> > > > > >
> > > > > > <xs:element name="author" type="test:personName"/>
> > > > > > </xs:schema>
> > > > > >
> > > > > > v3.xsd:
> > > > > > <xs:schema
targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > elementFormDefault="unqualified"
attributeFormDefault="unqualified">
> > > > > > <xs:include schemaLocation="v1.xsd"/>
> > > > > >
> > > > > > <xs:complexType name="marriedPersonName">
> > > > > > <xs:complexContent>
> > > > > > <xs:extension base="test:personName">
> > > > > > <xs:sequence>
> > > > > > <xs:element name="maidenName" type="xs:string"
minOccurs="0"/>
> > > > > > </xs:sequence>
> > > > > > </xs:extension>
> > > > > > </xs:complexContent>
> > > > > > </xs:complexType>
> > > > > >
> > > > > > <xs:element name="marriedPerson" type="test:marriedPersonName"/>
> > > > > >
> > > > > > </xs:schema>
> > > > > >
> > > > > > v4.xsd:
> > > > > > <xs:schema
targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > elementFormDefault="unqualified"
attributeFormDefault="unqualified">
> > > > > > <xs:include schemaLocation="v2.xsd"/>
> > > > > > <xs:include schemaLocation="v3.xsd"/>
> > > > > >
> > > > > > <xs:complexType name="people">
> > > > > > <xs:sequence>
> > > > > > <xs:element name="marriedPeople"
type="test:marriedPersonName"
> > > > > > maxOccurs="unbounded"/>
> > > > > > <xs:element name="singlePeople" type="test:personName"
> > > > > > maxOccurs="unbounded"/>
> > > > > > </xs:sequence>
> > > > > > </xs:complexType>
> > > > > > <xs:element name="directory" type="test:people"/>
> > > > > > </xs:schema>
> > > > > >
> > > > > > Ed Merks wrote:
> > > > > >
> > > > > > > James,
> > > > > >
> > > > > > > I'm not sure I can really answer the details of your questions
> > without
> > > > clear
> > > > > > > references to particular components in actual schema documents,
> > i.e., a
> > > > > > > sample. Perhaps it helps to explain that redefinition is
> > accomplished by
> > > > > > > making a clone of the schema being redefined and then modifying
that
> > copy
> > > > > > > according to the redefinition. The original schema is not
touched;
> > it
> > > > may be
> > > > > > > redefined many times in many different ways. The schema
containing
> > the
> > > > > > > redefine will see only the copy, not the original. Which version
you
> > get
> > > > will
> > > > > > > depend very much on where you ask, so you need to be specific...
> > > > > >
> > > > > > > James Taylor wrote:
> > > > > >
> > > > > > > > Hello,
> > > > > > > > If I understand the W3C spec correctly, a redefined complexType
> > should
> > > > be
> > > > > > > > used everywhere in place of the original type. For example,
if I
> > use
> > > > the
> > > > > > > > redefined complexType as a base type for another type, the
derived
> > type
> > > > > > > > should now include the additional elements introduced by the
> > redefined
> > > > > > > > type. This is not the behavior I'm seeing in Eclipse XSD.
When I
> > get
> > > > the
> > > > > > > > base type, using complexTypeDefinition.getBaseType(), I
continue
> > to get
> > > > > > > > the original definition instead of the redefined one.
References
> > to
> > > > the
> > > > > > > > type within the schema that has the redefine do point to the
new
> > > > redefined
> > > > > > > > type, though. Is this intentional? Should I use a different
> > > > mechanism to
> > > > > > > > get the base type? Or is this a bug?
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > >
> > > > > > > > James
Re: redefine [message #40108 is a reply to message #40038] Tue, 30 March 2004 11:28
 Eclipse User
Originally posted by: merks.ca.ibm.com

--------------CB5C521ADEF6460EF290FC80
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

James,

I think you need to show the example I showed below to get a clear answer to the
complete question. Multiple different redefines would normally cause a name
conflict, but not for the example below because the redefines are in different
namespaces and hence are redefining different abstract components. Unless someone
says the sample below is invalid and can point to some constraint in the spec that
would justify an error message for this case, then I will continue to consider the
case valid and will not make changes that would make that case stop working.

The case you show, modified as suggested in the answer to your question at the
schema forum, does work correctly now. Do you have cases without redundant (and
I'm still convinced, invalid) includes that don't work correctly?

James Taylor wrote:

> Ed,
>
> Thanks for fixing the bug you found and sorry about the error in
> Company.xsd. I sent a question to the W3C regarding redefines because I
> don't think the spec is as clear as it could be, and the answers I
> received clarify things:
>
> http://lists.w3.org/Archives/Public/xmlschema-dev/2004Mar/00 54.html
>
> I understand the revised example you've shown below is an alternative,
> however, it still should work the way I expressed it. The reason this is
> an important issue for us here at my company is that our schemas can
> become large with many levels of nesting. Being forced to redefine every
> encompassing type for all occurrences of a type becomes cumbersome and
> potentially error prone if an occurrence is missed. It can also prevents
> being able to redefine a type nested inside of element declaration with an
> anonymous type.
>
> I'll volunteer to fix it if that helps.
>
> James
>
> Ed Merks wrote:
> > James,
>
> > As I was fixing the Company.xsd to make it valid:
>
> > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > xmlns:test="http://namespaces.nextance.com/test"
> > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > elementFormDefault="unqualified" attributeFormDefault="unqualified">
>
> > <xs:redefine schemaLocation="Department.xsd">
> > <xs:complexType name="Employee">
> > <xs:complexContent>
> > <xs:extension base="test:Employee">
> > <xs:sequence>
> > <xs:element name="ranking" type="xs:int"/>
> > </xs:sequence>
> > </xs:extension>
> > </xs:complexContent>
> > </xs:complexType>
> > </xs:redefine>
>
> > <xs:complexType name="Company">
> > <xs:sequence>
> > <xs:element name="department" type="test:Department"
> > maxOccurs="unbounded"/>
> > <xs:element name="president" type="test:Employee"/>
> > </xs:sequence>
> > </xs:complexType>
>
> > <xs:element name="fortune500" type="test:Company"/>
>
> > </xs:schema>
>
> > I discovered that there is a bug that causes the transitive
> includes/redefines of a
> > cloned included/redefined schema to be omitted so I opened
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=56328 and have fixed that
> particular
> > problem. So, to my way of thinking, the above sample is the correct way to
> express
> > what you intended.
>
> > Consider the following slightly modified example where Employee.xsd has no
> > namespace:
>
> > <xs:schema
> > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > <xs:complexType name="Employee">
> > <xs:sequence>
> > <xs:element name="name" type="xs:string"/>
> > </xs:sequence>
> > </xs:complexType>
> > </xs:schema>
>
> > and Department.xsd is still the same (but the include is changing the null
> > namespace of the included schema to match that of the including schema):
>
> > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > xmlns:test="http://namespaces.nextance.com/test"
> > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > <xs:include schemaLocation="Employee.xsd"/>
>
> > <xs:complexType name="Department">
> > <xs:sequence>
> > <xs:element name="employee" type="test:Employee"
> > maxOccurs="unbounded"/>
> > <xs:element name="manager" type="test:Employee"/>
> > </xs:sequence>
> > </xs:complexType>
> > </xs:schema>
>
> > In this case, a Company.xsd can validly access both the original version of
> > Employee as well as a redefined version.
>
> > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > xmlns:test="http://namespaces.nextance.com/test"
> > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > elementFormDefault="unqualified" attributeFormDefault="unqualified">
>
> > <xs:import schemaLocation="Employee.xsd"/>
>
> > <xs:redefine schemaLocation="Department.xsd">
> > <xs:complexType name="Employee">
> > <xs:complexContent>
> > <xs:extension base="test:Employee">
> > <xs:sequence>
> > <xs:element name="ranking" type="xs:int"/>
> > </xs:sequence>
> > </xs:extension>
> > </xs:complexContent>
> > </xs:complexType>
> > </xs:redefine>
>
> > <xs:complexType name="Company">
> > <xs:sequence>
> > <xs:element name="department" type="test:Department"
> > maxOccurs="unbounded"/>
> > <xs:element name="president" type="test:Employee"/>
> > <xs:element name="dummy" type="Employee"/>
> > </xs:sequence>
> > </xs:complexType>
>
> > <xs:element name="fortune500" type="test:Company"/>
>
> > </xs:schema>
>
> > The semantics view for this shows that everyone is using the redefined type,
> except
> > the junk element, which is using the original:
>
> > [Image]
>
> > This stuff is all really much too complicated for human minds to handle (and
> I
> > think there are still lurking bugs in the implementation, but I don't have
> any more
> > time to spend to look at this further).
>
> > James Taylor wrote:
>
> > > Ed,
> > >
> > > Here's a smaller more realistic example that illustrates an issue:
> > >
> > > File A defines Employee type
> > > File B includes File A and defines Department type
> > > File C includes File B, redefines Employee from File A and defines Company
> > > type
> > >
> > > This is a common use case for redefine in which a type in a nested include
> > > needs to be redefined. With Eclipse XSD, the redefine does not affect the
> > > Employee type within the Department type and affects the Employee type
> > > within the Company type only if the include of File B precedes the
> > > redefine of File A. This does not seem like the correct behavior.
> > >
> > > I've included the XSD files below. Thanks,
> > >
> > > James
> > >
> > > Employee.xsd:
> > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > xmlns:test="http://namespaces.nextance.com/test"
> > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > <xs:complexType name="Employee">
> > > <xs:sequence>
> > > <xs:element name="name" type="xs:string"/>
> > > </xs:sequence>
> > > </xs:complexType>
> > > </xs:schema>
> > >
> > > Department.xsd:
> > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > xmlns:test="http://namespaces.nextance.com/test"
> > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > <xs:include schemaLocation="Employee.xsd"/>
> > >
> > > <xs:complexType name="Department">
> > > <xs:sequence>
> > > <xs:element name="employee" type="test:Employee"
> > > maxOccurs="unbounded"/>
> > > <xs:element name="manager" type="test:Employee"/>
> > > </xs:sequence>
> > > </xs:complexType>
> > > </xs:schema>
> > >
> > > Company.xsd:
> > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > xmlns:test="http://namespaces.nextance.com/test"
> > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > >
> > > <xs:include schemaLocation="Department.xsd"/>
> > >
> > > <xs:redefine schemaLocation="Employee.xsd">
> > > <xs:complexType name="Employee">
> > > <xs:complexContent>
> > > <xs:extension base="test:Employee">
> > > <xs:sequence>
> > > <xs:element name="ranking" type="xs:int"/>
> > > </xs:sequence>
> > > </xs:extension>
> > > </xs:complexContent>
> > > </xs:complexType>
> > > </xs:redefine>
> > >
> > > <xs:complexType name="Company">
> > > <xs:sequence>
> > > <xs:element name="department" type="test:Department"
> > > maxOccurs="unbounded"/>
> > > <xs:element name="president" type="test:Employee"/>
> > > </xs:sequence>
> > > </xs:complexType>
> > >
> > > <xs:element name="fortune500" type="test:Company" maxOccurs="500"/>
> > >
> > > </xs:schema>
> > >
> > > Ed Merks wrote:
> > >
> > > > James,
> > >
> > > > All the components of the schema mentioned in the redefine are
> incorporated
> > > (i.e.,
> > > > cloned) and the redefinitions are pervasively applied to all the
> components
> > > in that
> > > > clone. Note that if the schema being redefined has a null target
> namespace,
> > > it may
> > > > be redefined in multiple schemas each with a different namespace and
> each
> > > in a
> > > > different way; in this case, during incorporation, the namespace of the
> > > clone is
> > > > modified to match the namespace of the redefining schema and the other
> > > redefinition
> > > > modifications are applied as well. In any event, the original schema
> remains
> > > > untouched so that it can and will be reused in its pristine form when
> > > referenced
> > > > directly.
> > >
> > > > James Taylor wrote:
> > >
> > > > > Ed,
> > > > >
> > > > > Thank you for the explanation. It's not clear to me how "pervasive"
> the
> > > > > W3C spec
> > > > > ( http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#modify-s chema)
> meant
> > > > > a redefine to be when they state:
> > > > >
> > > > > The modifications have a pervasive impact, that is, only the
> redefined
> > > > > components are used, even when referenced from other incorporated
> > > > > components, whether redefined themselves or not.
> > > > >
> > > > > Given that later in the spec they imply that multiple redefines of the
> > > > > same type that conflict are not legal, I assume they meant that the
> > > > > redefined type should "pervade" everywhere, including in my example of
> > > > > v4.xsd.
> > > > >
> > > > > James
> > > > >
> > > > > Ed Merks wrote:
> > > > >
> > > > > > James,
> > > > >
> > > > > > The v4.xsd schema isn't valid because its includes both a redefined
> > > version
> > > > > of
> > > > > > personName and addressee, via its include of v2.xsd's redefinition of
> > > > > v1.xsd, as
> > > > > > well as the original version of personName and addressee, via its
> > > include of
> > > > > > v3.xsd's include of v1.xsd without redefinition. The v3.xsd schema
> > > needs to
> > > > > > include v2.xsd not v1.xsd for this example to be valid. The bottom
> line
> > > is
> > > > > that
> > > > > > v1.xsd is not modified by virtue of the redefine in v2.xsd; only
> v2.xsd
> > > sees
> > > > > that
> > > > > > redefinition directly and any schema importing or including v2.xsd
> will
> > > see
> > > > > that
> > > > > > redefinition indirectly; but v3.xsd sees only the original v1.xsd and
> > > knows
> > > > > nothing
> > > > > > of v2.xsd. When we get to v4.xsd, the result is name collision.
> > > > >
> > > > > > James Taylor wrote:
> > > > >
> > > > > > > Ed,
> > > > > > >
> > > > > > > Thanks for the reply. My sample is below. In v4.xsd, I would have
> > > > > > > expected that the "marriedPeople" element would contain the
> > > "generation"
> > > > > > > element since it is redefined to include this in v2.xsd. The
> > > > > > > "singlePeople" element does include the "generation" element as
> > > expected.
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > James
> > > > > > >
> > > > > > > v1.xsd:
> > > > > > > <xs:schema
> targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > > elementFormDefault="unqualified"
> attributeFormDefault="unqualified">
> > > > > > > <xs:complexType name="personName">
> > > > > > > <xs:sequence>
> > > > > > > <xs:element name="title" type="xs:string" minOccurs="0"/>
> > > > > > > <xs:element name="forename" type="xs:string" minOccurs="0"
> > > > > > > maxOccurs="unbounded"/>
> > > > > > > </xs:sequence>
> > > > > > > </xs:complexType>
> > > > > > >
> > > > > > > <xs:element name="addressee" type="test:personName"/>
> > > > > > > </xs:schema>
> > > > > > >
> > > > > > > v2.xsd:
> > > > > > > <xs:schema
> targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > > elementFormDefault="unqualified"
> attributeFormDefault="unqualified">
> > > > > > > <xs:redefine schemaLocation="v1.xsd">
> > > > > > > <xs:complexType name="personName">
> > > > > > > <xs:complexContent>
> > > > > > > <xs:extension base="test:personName">
> > > > > > > <xs:sequence>
> > > > > > > <xs:element name="generation" type="xs:string"
> minOccurs="0"/>
> > > > > > > </xs:sequence>
> > > > > > > </xs:extension>
> > > > > > > </xs:complexContent>
> > > > > > > </xs:complexType>
> > > > > > > </xs:redefine>
> > > > > > >
> > > > > > > <xs:element name="author" type="test:personName"/>
> > > > > > > </xs:schema>
> > > > > > >
> > > > > > > v3.xsd:
> > > > > > > <xs:schema
> targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > > elementFormDefault="unqualified"
> attributeFormDefault="unqualified">
> > > > > > > <xs:include schemaLocation="v1.xsd"/>
> > > > > > >
> > > > > > > <xs:complexType name="marriedPersonName">
> > > > > > > <xs:complexContent>
> > > > > > > <xs:extension base="test:personName">
> > > > > > > <xs:sequence>
> > > > > > > <xs:element name="maidenName" type="xs:string"
> minOccurs="0"/>
> > > > > > > </xs:sequence>
> > > > > > > </xs:extension>
> > > > > > > </xs:complexContent>
> > > > > > > </xs:complexType>
> > > > > > >
> > > > > > > <xs:element name="marriedPerson" type="test:marriedPersonName"/>
> > > > > > >
> > > > > > > </xs:schema>
> > > > > > >
> > > > > > > v4.xsd:
> > > > > > > <xs:schema
> targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > > elementFormDefault="unqualified"
> attributeFormDefault="unqualified">
> > > > > > > <xs:include schemaLocation="v2.xsd"/>
> > > > > > > <xs:include schemaLocation="v3.xsd"/>
> > > > > > >
> > > > > > > <xs:complexType name="people">
> > > > > > > <xs:sequence>
> > > > > > > <xs:element name="marriedPeople"
> type="test:marriedPersonName"
> > > > > > > maxOccurs="unbounded"/>
> > > > > > > <xs:element name="singlePeople" type="test:personName"
> > > > > > > maxOccurs="unbounded"/>
> > > > > > > </xs:sequence>
> > > > > > > </xs:complexType>
> > > > > > > <xs:element name="directory" type="test:people"/>
> > > > > > > </xs:schema>
> > > > > > >
> > > > > > > Ed Merks wrote:
> > > > > > >
> > > > > > > > James,
> > > > > > >
> > > > > > > > I'm not sure I can really answer the details of your questions
> > > without
> > > > > clear
> > > > > > > > references to particular components in actual schema documents,
> > > i.e., a
> > > > > > > > sample. Perhaps it helps to explain that redefinition is
> > > accomplished by
> > > > > > > > making a clone of the schema being redefined and then modifying
> that
> > > copy
> > > > > > > > according to the redefinition. The original schema is not
> touched;
> > > it
> > > > > may be
> > > > > > > > redefined many times in many different ways. The schema
> containing
> > > the
> > > > > > > > redefine will see only the copy, not the original. Which version
> you
> > > get
> > > > > will
> > > > > > > > depend very much on where you ask, so you need to be specific...
> > > > > > >
> > > > > > > > James Taylor wrote:
> > > > > > >
> > > > > > > > > Hello,
> > > > > > > > > If I understand the W3C spec correctly, a redefined complexType
> > > should
> > > > > be
> > > > > > > > > used everywhere in place of the original type. For example,
> if I
> > > use
> > > > > the
> > > > > > > > > redefined complexType as a base type for another type, the
> derived
> > > type
> > > > > > > > > should now include the additional elements introduced by the
> > > redefined
> > > > > > > > > type. This is not the behavior I'm seeing in Eclipse XSD.
> When I
> > > get
> > > > > the
> > > > > > > > > base type, using complexTypeDefinition.getBaseType(), I
> continue
> > > to get
> > > > > > > > > the original definition instead of the redefined one.
> References
> > > to
> > > > > the
> > > > > > > > > type within the schema that has the redefine do point to the
> new
> > > > > redefined
> > > > > > > > > type, though. Is this intentional? Should I use a different
> > > > > mechanism to
> > > > > > > > > get the base type? Or is this a bug?
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > >
> > > > > > > > > James

--------------CB5C521ADEF6460EF290FC80
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
James,
<p>I think you need to show the example I showed below to get a clear answer
to the complete question.&nbsp; Multiple different redefines would normally
cause a name conflict, but not for the example below because the redefines
are in different namespaces and hence are redefining different abstract
components.&nbsp; Unless someone says the sample below is invalid <b>and</b>
can point to some constraint in the spec that would justify an error message
for this case, then I will continue to consider the case valid and will
not make changes that would make that case stop working.
<p>The case you show, modified as suggested in the answer to your question
at the schema forum, does work correctly now.&nbsp; Do you have cases without
redundant (and I'm still convinced, invalid) includes that don't work correctly?
<br>&nbsp;
<p>James Taylor wrote:
<blockquote TYPE=CITE>Ed,
<p>Thanks for fixing the bug you found and sorry about the error in
<br>Company.xsd.&nbsp; I sent a question to the W3C regarding redefines
because I
<br>don't think the spec is as clear as it could be, and the answers I
<br>received clarify things:
<p><a href=" http://lists.w3.org/Archives/Public/xmlschema-dev/2004Mar/00 54.html"> http://lists.w3.org/Archives/Public/xmlschema-dev/2004Mar/00 54.html</a>
<p>I understand the revised example you've shown below is an alternative,
<br>however, it still should work the way I expressed it.&nbsp; The reason
this is
<br>an important issue for us here at my company is that our schemas can
<br>become large with many levels of nesting.&nbsp; Being forced to redefine
every
<br>encompassing type for all occurrences of a type becomes cumbersome
and
<br>potentially error prone if an occurrence is missed.&nbsp; It can also
prevents
<br>being able to redefine a type nested inside of element declaration
with an
<br>anonymous type.
<p>I'll volunteer to fix it if that helps.
<p>&nbsp;&nbsp;&nbsp; James
<p>Ed Merks wrote:
<br>> James,
<p>> As I was fixing the Company.xsd to make it valid:
<p>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:schema targetNamespace="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; xmlns:test="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; xmlns:xs="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; elementFormDefault="unqualified" attributeFormDefault="unqualified">
<p>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;xs:redefine schemaLocation="Department.xsd">
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &lt;xs:complexType
name="Employee">
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xs:complexContent>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;
&lt;xs:extension base="test:Employee">
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
&lt;xs:sequence>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xs:element name="ranking" type="xs:int"/>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
&lt;/xs:sequence>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;
&lt;/xs:extension>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;/xs:complexContent>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &lt;/xs:complexType>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;/xs:redefine>
<p>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;xs:complexType name="Company">
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &lt;xs:sequence>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xs:element name="department" type="test:Department"
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; maxOccurs="unbounded"/>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xs:element name="president" type="test:Employee"/>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &lt;/xs:sequence>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;/xs:complexType>
<p>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;xs:element name="fortune500"
type="test:Company"/>
<p>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:schema>
<p>> I discovered that there is a bug that causes the transitive
<br>includes/redefines of a
<br>> cloned included/redefined schema to be omitted so I opened
<br>> <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=56328">https://bugs.eclipse.org/bugs/show_bug.cgi?id=56328</a>
and have fixed that
<br>particular
<br>> problem. So, to my way of thinking, the above sample is the correct
way to
<br>express
<br>> what you intended.
<p>> Consider the following slightly modified example where Employee.xsd
has no
<br>> namespace:
<p>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:schema
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; xmlns:xs="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; elementFormDefault="unqualified" attributeFormDefault="unqualified">
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;xs:complexType name="Employee">
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &lt;xs:sequence>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xs:element name="name" type="xs:string"/>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &lt;/xs:sequence>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;/xs:complexType>
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:schema>
<p>> and Department.xsd is still the same (but the include is changing
the null
<br>> namespace of the included schema to match that of the including schema):
<p>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:schema targetNamespace="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; xmlns:test="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; xmlns:xs="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; elementFormDefault="unqualified" attributeFormDefault="unqualified">
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;xs:include schemaLocation="Employee.xsd"/>
<p>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;xs:complexType name="Department">
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &lt;xs:sequence>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xs:element name="employee" type="test:Employee"
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; maxOccurs="unbounded"/>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xs:element name="manager" type="test:Employee"/>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &lt;/xs:sequence>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;/xs:complexType>
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:schema>
<p>> In this case, a Company.xsd can validly access both the original version
of
<br>> Employee as well as a redefined version.
<p>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:schema targetNamespace="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; xmlns:test="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; xmlns:xs="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; elementFormDefault="unqualified" attributeFormDefault="unqualified">
<p>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;xs:import schemaLocation="Employee.xsd"/>
<p>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;xs:redefine schemaLocation="Department.xsd">
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &lt;xs:complexType
name="Employee">
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xs:complexContent>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;
&lt;xs:extension base="test:Employee">
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
&lt;xs:sequence>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xs:element name="ranking" type="xs:int"/>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
&lt;/xs:sequence>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;
&lt;/xs:extension>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;/xs:complexContent>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &lt;/xs:complexType>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;/xs:redefine>
<p>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;xs:complexType name="Company">
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &lt;xs:sequence>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xs:element name="department" type="test:Department"
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; maxOccurs="unbounded"/>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xs:element name="president" type="test:Employee"/>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xs:element name="dummy" type="Employee"/>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &lt;/xs:sequence>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;/xs:complexType>
<p>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;xs:element name="fortune500"
type="test:Company"/>
<p>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:schema>
<p>> The semantics view for this shows that everyone is using the redefined
type,
<br>except
<br>> the junk element, which is using the original:
<p>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [Image]
<p>> This stuff is all really much too complicated for human minds to handle
(and
<br>I
<br>> think there are still lurking bugs in the implementation, but I don't
have
<br>any more
<br>> time to spend to look at this further).
<p>> James Taylor wrote:
<p>> > Ed,
<br>> >
<br>> > Here's a smaller more realistic example that illustrates an issue:
<br>> >
<br>> > File A defines Employee type
<br>> > File B includes File A and defines Department type
<br>> > File C includes File B, redefines Employee from File A and defines
Company
<br>> > type
<br>> >
<br>> > This is a common use case for redefine in which a type in a nested
include
<br>> > needs to be redefined.&nbsp; With Eclipse XSD, the redefine does
not affect the
<br>> > Employee type within the Department type and affects the Employee
type
<br>> > within the Company type only if the include of File B precedes
the
<br>> > redefine of File A.&nbsp; This does not seem like the correct behavior.
<br>> >
<br>> > I've included the XSD files below.&nbsp; Thanks,
<br>> >
<br>> >&nbsp;&nbsp;&nbsp;&nbsp; James
<br>> >
<br>> > Employee.xsd:
<br>> > &lt;xs:schema targetNamespace="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>> > xmlns:test="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>> > xmlns:xs="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>> > elementFormDefault="unqualified" attributeFormDefault="unqualified">
<br>> >&nbsp;&nbsp; &lt;xs:complexType name="Employee">
<br>> >&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:sequence>
<br>> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="name"
type="xs:string"/>
<br>> >&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:sequence>
<br>> >&nbsp;&nbsp; &lt;/xs:complexType>
<br>> > &lt;/xs:schema>
<br>> >
<br>> > Department.xsd:
<br>> > &lt;xs:schema targetNamespace="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>> > xmlns:test="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>> > xmlns:xs="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>> > elementFormDefault="unqualified" attributeFormDefault="unqualified">
<br>> >&nbsp;&nbsp; &lt;xs:include schemaLocation="Employee.xsd"/>
<br>> >
<br>> >&nbsp;&nbsp; &lt;xs:complexType name="Department">
<br>> >&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:sequence>
<br>> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="employee"
type="test:Employee"
<br>> > maxOccurs="unbounded"/>
<br>> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="manager"
type="test:Employee"/>
<br>> >&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:sequence>
<br>> >&nbsp;&nbsp; &lt;/xs:complexType>
<br>> > &lt;/xs:schema>
<br>> >
<br>> > Company.xsd:
<br>> > &lt;xs:schema targetNamespace="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>> > xmlns:test="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>> > xmlns:xs="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>> > elementFormDefault="unqualified" attributeFormDefault="unqualified">
<br>> >
<br>> >&nbsp;&nbsp; &lt;xs:include schemaLocation="Department.xsd"/>
<br>> >
<br>> >&nbsp;&nbsp; &lt;xs:redefine schemaLocation="Employee.xsd">
<br>> >&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:complexType name="Employee">
<br>> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:complexContent>
<br>> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; &lt;xs:extension
base="test:Employee">
<br>> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:sequence>
<br>> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xs:element name="ranking" type="xs:int"/>
<br>> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:sequence>
<br>> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; &lt;/xs:extension>
<br>> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:complexContent>
<br>> >&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:complexType>
<br>> >&nbsp;&nbsp; &lt;/xs:redefine>
<br>> >
<br>> >&nbsp;&nbsp; &lt;xs:complexType name="Company">
<br>> >&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:sequence>
<br>> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="department"
type="test:Department"
<br>> > maxOccurs="unbounded"/>
<br>> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="president"
type="test:Employee"/>
<br>> >&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:sequence>
<br>> >&nbsp;&nbsp; &lt;/xs:complexType>
<br>> >
<br>> >&nbsp;&nbsp; &lt;xs:element name="fortune500" type="test:Company"
maxOccurs="500"/>
<br>> >
<br>> > &lt;/xs:schema>
<br>> >
<br>> > Ed Merks wrote:
<br>> >
<br>> > > James,
<br>> >
<br>> > > All the components of the schema mentioned in the redefine are
<br>incorporated
<br>> > (i.e.,
<br>> > > cloned) and the redefinitions are pervasively applied to all
the
<br>components
<br>> > in that
<br>> > > clone.&nbsp; Note that if the schema being redefined has a null
target
<br>namespace,
<br>> > it may
<br>> > > be redefined in&nbsp; multiple schemas each with a different
namespace and
<br>each
<br>> > in a
<br>> > > different way; in this case, during incorporation, the namespace
of the
<br>> > clone is
<br>> > > modified to match the namespace of the redefining schema and
the other
<br>> > redefinition
<br>> > > modifications are applied as well.&nbsp; In any event, the original
schema
<br>remains
<br>> > > untouched so that it can and will be reused in its pristine form
when
<br>> > referenced
<br>> > > directly.
<br>> >
<br>> > > James Taylor wrote:
<br>> >
<br>> > > > Ed,
<br>> > > >
<br>> > > > Thank you for the explanation.&nbsp; It's not clear to me how
"pervasive"
<br>the
<br>> > > > W3C spec
<br>> > > > (<a href=" http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#modify-s chema"> http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#modify-s chema</a>)
<br>meant
<br>> > > > a redefine to be when they state:
<br>> > > >
<br>> > > >&nbsp;&nbsp;&nbsp;&nbsp; The modifications have a pervasive
impact, that is, only the
<br>redefined
<br>> > > >&nbsp;&nbsp;&nbsp;&nbsp; components are used, even when referenced
from other incorporated
<br>> > > >&nbsp;&nbsp;&nbsp;&nbsp; components, whether redefined themselves
or not.
<br>> > > >
<br>> > > > Given that later in the spec they imply that multiple redefines
of the
<br>> > > > same type that conflict are not legal, I assume they meant
that the
<br>> > > > redefined type should "pervade" everywhere, including in my
example of
<br>> > > > v4.xsd.
<br>> > > >
<br>> > > >&nbsp;&nbsp;&nbsp;&nbsp; James
<br>> > > >
<br>> > > > Ed Merks wrote:
<br>> > > >
<br>> > > > > James,
<br>> > > >
<br>> > > > > The v4.xsd schema isn't valid because its includes both a
redefined
<br>> > version
<br>> > > > of
<br>> > > > > personName and addressee, via its include of v2.xsd's redefinition
of
<br>> > > > v1.xsd, as
<br>> > > > > well as the original version of personName and addressee,
via its
<br>> > include of
<br>> > > > > v3.xsd's include of v1.xsd without redefinition.&nbsp; The
v3.xsd schema
<br>> > needs to
<br>> > > > > include v2.xsd not v1.xsd for this example to be valid.&nbsp;
The bottom
<br>line
<br>> > is
<br>> > > > that
<br>> > > > > v1.xsd is not modified by virtue of the redefine in v2.xsd;
only
<br>v2.xsd
<br>> > sees
<br>> > > > that
<br>> > > > > redefinition directly and any schema importing or including
v2.xsd
<br>will
<br>> > see
<br>> > > > that
<br>> > > > > redefinition indirectly; but v3.xsd sees only the original
v1.xsd and
<br>> > knows
<br>> > > > nothing
<br>> > > > > of v2.xsd.&nbsp; When we get to v4.xsd, the result is name
collision.
<br>> > > >
<br>> > > > > James Taylor wrote:
<br>> > > >
<br>> > > > > > Ed,
<br>> > > > > >
<br>> > > > > > Thanks for the reply.&nbsp; My sample is below.&nbsp; In
v4.xsd, I would have
<br>> > > > > > expected that the "marriedPeople" element would contain
the
<br>> > "generation"
<br>> > > > > > element since it is redefined to include this in v2.xsd.&nbsp;
The
<br>> > > > > > "singlePeople" element does include the "generation" element
as
<br>> > expected.
<br>> > > > > >
<br>> > > > > > Thanks,
<br>> > > > > >
<br>> > > > > >&nbsp;&nbsp;&nbsp;&nbsp; James
<br>> > > > > >
<br>> > > > > > v1.xsd:
<br>> > > > > > &lt;xs:schema
<br>targetNamespace="<a href="http://namespaces.nextance.com/nex/test">http://namespaces.nextance.com/
Re: redefine [message #40269 is a reply to message #40108] Wed, 31 March 2004 00:16
 Eclipse User
Originally posted by: jtaylor.nextance.com

Ed,

I got the latest XSD from CVS and everything works fine. Thanks again for
the bug fix -- I didn't realize it fixed my test case. I agree with you
that your example should work as well, since there are really two Employee
types one with no namespace and the other with a namespace. I tried it
with the W3C schema validator (XSV) against a test instance and it worked
fine.

James

Ed Merks wrote:

> James,

> I think you need to show the example I showed below to get a clear answer to
the
> complete question. Multiple different redefines would normally cause a name
> conflict, but not for the example below because the redefines are in
different
> namespaces and hence are redefining different abstract components. Unless
someone
> says the sample below is invalid and can point to some constraint in the
spec that
> would justify an error message for this case, then I will continue to
consider the
> case valid and will not make changes that would make that case stop working.

> The case you show, modified as suggested in the answer to your question at
the
> schema forum, does work correctly now. Do you have cases without redundant
(and
> I'm still convinced, invalid) includes that don't work correctly?

> James Taylor wrote:

> > Ed,
> >
> > Thanks for fixing the bug you found and sorry about the error in
> > Company.xsd. I sent a question to the W3C regarding redefines because I
> > don't think the spec is as clear as it could be, and the answers I
> > received clarify things:
> >
> > http://lists.w3.org/Archives/Public/xmlschema-dev/2004Mar/00 54.html
> >
> > I understand the revised example you've shown below is an alternative,
> > however, it still should work the way I expressed it. The reason this is
> > an important issue for us here at my company is that our schemas can
> > become large with many levels of nesting. Being forced to redefine every
> > encompassing type for all occurrences of a type becomes cumbersome and
> > potentially error prone if an occurrence is missed. It can also prevents
> > being able to redefine a type nested inside of element declaration with an
> > anonymous type.
> >
> > I'll volunteer to fix it if that helps.
> >
> > James
> >
> > Ed Merks wrote:
> > > James,
> >
> > > As I was fixing the Company.xsd to make it valid:
> >
> > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > xmlns:test="http://namespaces.nextance.com/test"
> > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> >
> > > <xs:redefine schemaLocation="Department.xsd">
> > > <xs:complexType name="Employee">
> > > <xs:complexContent>
> > > <xs:extension base="test:Employee">
> > > <xs:sequence>
> > > <xs:element name="ranking" type="xs:int"/>
> > > </xs:sequence>
> > > </xs:extension>
> > > </xs:complexContent>
> > > </xs:complexType>
> > > </xs:redefine>
> >
> > > <xs:complexType name="Company">
> > > <xs:sequence>
> > > <xs:element name="department" type="test:Department"
> > > maxOccurs="unbounded"/>
> > > <xs:element name="president" type="test:Employee"/>
> > > </xs:sequence>
> > > </xs:complexType>
> >
> > > <xs:element name="fortune500" type="test:Company"/>
> >
> > > </xs:schema>
> >
> > > I discovered that there is a bug that causes the transitive
> > includes/redefines of a
> > > cloned included/redefined schema to be omitted so I opened
> > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=56328 and have fixed that
> > particular
> > > problem. So, to my way of thinking, the above sample is the correct way
to
> > express
> > > what you intended.
> >
> > > Consider the following slightly modified example where Employee.xsd has
no
> > > namespace:
> >
> > > <xs:schema
> > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > <xs:complexType name="Employee">
> > > <xs:sequence>
> > > <xs:element name="name" type="xs:string"/>
> > > </xs:sequence>
> > > </xs:complexType>
> > > </xs:schema>
> >
> > > and Department.xsd is still the same (but the include is changing the
null
> > > namespace of the included schema to match that of the including schema):
> >
> > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > xmlns:test="http://namespaces.nextance.com/test"
> > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > <xs:include schemaLocation="Employee.xsd"/>
> >
> > > <xs:complexType name="Department">
> > > <xs:sequence>
> > > <xs:element name="employee" type="test:Employee"
> > > maxOccurs="unbounded"/>
> > > <xs:element name="manager" type="test:Employee"/>
> > > </xs:sequence>
> > > </xs:complexType>
> > > </xs:schema>
> >
> > > In this case, a Company.xsd can validly access both the original version
of
> > > Employee as well as a redefined version.
> >
> > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > xmlns:test="http://namespaces.nextance.com/test"
> > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> >
> > > <xs:import schemaLocation="Employee.xsd"/>
> >
> > > <xs:redefine schemaLocation="Department.xsd">
> > > <xs:complexType name="Employee">
> > > <xs:complexContent>
> > > <xs:extension base="test:Employee">
> > > <xs:sequence>
> > > <xs:element name="ranking" type="xs:int"/>
> > > </xs:sequence>
> > > </xs:extension>
> > > </xs:complexContent>
> > > </xs:complexType>
> > > </xs:redefine>
> >
> > > <xs:complexType name="Company">
> > > <xs:sequence>
> > > <xs:element name="department" type="test:Department"
> > > maxOccurs="unbounded"/>
> > > <xs:element name="president" type="test:Employee"/>
> > > <xs:element name="dummy" type="Employee"/>
> > > </xs:sequence>
> > > </xs:complexType>
> >
> > > <xs:element name="fortune500" type="test:Company"/>
> >
> > > </xs:schema>
> >
> > > The semantics view for this shows that everyone is using the redefined
type,
> > except
> > > the junk element, which is using the original:
> >
> > > [Image]
> >
> > > This stuff is all really much too complicated for human minds to handle
(and
> > I
> > > think there are still lurking bugs in the implementation, but I don't
have
> > any more
> > > time to spend to look at this further).
> >
> > > James Taylor wrote:
> >
> > > > Ed,
> > > >
> > > > Here's a smaller more realistic example that illustrates an issue:
> > > >
> > > > File A defines Employee type
> > > > File B includes File A and defines Department type
> > > > File C includes File B, redefines Employee from File A and defines
Company
> > > > type
> > > >
> > > > This is a common use case for redefine in which a type in a nested
include
> > > > needs to be redefined. With Eclipse XSD, the redefine does not affect
the
> > > > Employee type within the Department type and affects the Employee type
> > > > within the Company type only if the include of File B precedes the
> > > > redefine of File A. This does not seem like the correct behavior.
> > > >
> > > > I've included the XSD files below. Thanks,
> > > >
> > > > James
> > > >
> > > > Employee.xsd:
> > > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > > xmlns:test="http://namespaces.nextance.com/test"
> > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > <xs:complexType name="Employee">
> > > > <xs:sequence>
> > > > <xs:element name="name" type="xs:string"/>
> > > > </xs:sequence>
> > > > </xs:complexType>
> > > > </xs:schema>
> > > >
> > > > Department.xsd:
> > > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > > xmlns:test="http://namespaces.nextance.com/test"
> > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > <xs:include schemaLocation="Employee.xsd"/>
> > > >
> > > > <xs:complexType name="Department">
> > > > <xs:sequence>
> > > > <xs:element name="employee" type="test:Employee"
> > > > maxOccurs="unbounded"/>
> > > > <xs:element name="manager" type="test:Employee"/>
> > > > </xs:sequence>
> > > > </xs:complexType>
> > > > </xs:schema>
> > > >
> > > > Company.xsd:
> > > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > > xmlns:test="http://namespaces.nextance.com/test"
> > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > >
> > > > <xs:include schemaLocation="Department.xsd"/>
> > > >
> > > > <xs:redefine schemaLocation="Employee.xsd">
> > > > <xs:complexType name="Employee">
> > > > <xs:complexContent>
> > > > <xs:extension base="test:Employee">
> > > > <xs:sequence>
> > > > <xs:element name="ranking" type="xs:int"/>
> > > > </xs:sequence>
> > > > </xs:extension>
> > > > </xs:complexContent>
> > > > </xs:complexType>
> > > > </xs:redefine>
> > > >
> > > > <xs:complexType name="Company">
> > > > <xs:sequence>
> > > > <xs:element name="department" type="test:Department"
> > > > maxOccurs="unbounded"/>
> > > > <xs:element name="president" type="test:Employee"/>
> > > > </xs:sequence>
> > > > </xs:complexType>
> > > >
> > > > <xs:element name="fortune500" type="test:Company" maxOccurs="500"/>
> > > >
> > > > </xs:schema>
> > > >
> > > > Ed Merks wrote:
> > > >
> > > > > James,
> > > >
> > > > > All the components of the schema mentioned in the redefine are
> > incorporated
> > > > (i.e.,
> > > > > cloned) and the redefinitions are pervasively applied to all the
> > components
> > > > in that
> > > > > clone. Note that if the schema being redefined has a null target
> > namespace,
> > > > it may
> > > > > be redefined in multiple schemas each with a different namespace and
> > each
> > > > in a
> > > > > different way; in this case, during incorporation, the namespace of
the
> > > > clone is
> > > > > modified to match the namespace of the redefining schema and the
other
> > > > redefinition
> > > > > modifications are applied as well. In any event, the original schema
> > remains
> > > > > untouched so that it can and will be reused in its pristine form when
> > > > referenced
> > > > > directly.
> > > >
> > > > > James Taylor wrote:
> > > >
> > > > > > Ed,
> > > > > >
> > > > > > Thank you for the explanation. It's not clear to me how
"pervasive"
> > the
> > > > > > W3C spec
> > > > > > ( http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#modify-s chema)
> > meant
> > > > > > a redefine to be when they state:
> > > > > >
> > > > > > The modifications have a pervasive impact, that is, only the
> > redefined
> > > > > > components are used, even when referenced from other
incorporated
> > > > > > components, whether redefined themselves or not.
> > > > > >
> > > > > > Given that later in the spec they imply that multiple redefines of
the
> > > > > > same type that conflict are not legal, I assume they meant that the
> > > > > > redefined type should "pervade" everywhere, including in my
example of
> > > > > > v4.xsd.
> > > > > >
> > > > > > James
> > > > > >
> > > > > > Ed Merks wrote:
> > > > > >
> > > > > > > James,
> > > > > >
> > > > > > > The v4.xsd schema isn't valid because its includes both a
redefined
> > > > version
> > > > > > of
> > > > > > > personName and addressee, via its include of v2.xsd's
redefinition of
> > > > > > v1.xsd, as
> > > > > > > well as the original version of personName and addressee, via its
> > > > include of
> > > > > > > v3.xsd's include of v1.xsd without redefinition. The v3.xsd
schema
> > > > needs to
> > > > > > > include v2.xsd not v1.xsd for this example to be valid. The
bottom
> > line
> > > > is
> > > > > > that
> > > > > > > v1.xsd is not modified by virtue of the redefine in v2.xsd; only
> > v2.xsd
> > > > sees
> > > > > > that
> > > > > > > redefinition directly and any schema importing or including
v2.xsd
> > will
> > > > see
> > > > > > that
> > > > > > > redefinition indirectly; but v3.xsd sees only the original
v1.xsd and
> > > > knows
> > > > > > nothing
> > > > > > > of v2.xsd. When we get to v4.xsd, the result is name collision.
> > > > > >
> > > > > > > James Taylor wrote:
> > > > > >
> > > > > > > > Ed,
> > > > > > > >
> > > > > > > > Thanks for the reply. My sample is below. In v4.xsd, I would
have
> > > > > > > > expected that the "marriedPeople" element would contain the
> > > > "generation"
> > > > > > > > element since it is redefined to include this in v2.xsd. The
> > > > > > > > "singlePeople" element does include the "generation" element as
> > > > expected.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > >
> > > > > > > > James
> > > > > > > >
> > > > > > > > v1.xsd:
> > > > > > > > <xs:schema
> > targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > > > elementFormDefault="unqualified"
> > attributeFormDefault="unqualified">
> > > > > > > > <xs:complexType name="personName">
> > > > > > > > <xs:sequence>
> > > > > > > > <xs:element name="title" type="xs:string" minOccurs="0"/>
> > > > > > > > <xs:element name="forename" type="xs:string" minOccurs="0"
> > > > > > > > maxOccurs="unbounded"/>
> > > > > > > > </xs:sequence>
> > > > > > > > </xs:complexType>
> > > > > > > >
> > > > > > > > <xs:element name="addressee" type="test:personName"/>
> > > > > > > > </xs:schema>
> > > > > > > >
> > > > > > > > v2.xsd:
> > > > > > > > <xs:schema
> > targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > > > elementFormDefault="unqualified"
> > attributeFormDefault="unqualified">
> > > > > > > > <xs:redefine schemaLocation="v1.xsd">
> > > > > > > > <xs:complexType name="personName">
> > > > > > > > <xs:complexContent>
> > > > > > > > <xs:extension base="test:personName">
> > > > > > > > <xs:sequence>
> > > > > > > > <xs:element name="generation" type="xs:string"
> > minOccurs="0"/>
> > > > > > > > </xs:sequence>
> > > > > > > > </xs:extension>
> > > > > > > > </xs:complexContent>
> > > > > > > > </xs:complexType>
> > > > > > > > </xs:redefine>
> > > > > > > >
> > > > > > > > <xs:element name="author" type="test:personName"/>
> > > > > > > > </xs:schema>
> > > > > > > >
> > > > > > > > v3.xsd:
> > > > > > > > <xs:schema
> > targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > > > elementFormDefault="unqualified"
> > attributeFormDefault="unqualified">
> > > > > > > > <xs:include schemaLocation="v1.xsd"/>
> > > > > > > >
> > > > > > > > <xs:complexType name="marriedPersonName">
> > > > > > > > <xs:complexContent>
> > > > > > > > <xs:extension base="test:personName">
> > > > > > > > <xs:sequence>
> > > > > > > > <xs:element name="maidenName" type="xs:string"
> > minOccurs="0"/>
> > > > > > > > </xs:sequence>
> > > > > > > > </xs:extension>
> > > > > > > > </xs:complexContent>
> > > > > > > > </xs:complexType>
> > > > > > > >
> > > > > > > > <xs:element name="marriedPerson"
type="test:marriedPersonName"/>
> > > > > > > >
> > > > > > > > </xs:schema>
> > > > > > > >
> > > > > > > > v4.xsd:
> > > > > > > > <xs:schema
> > targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > > > elementFormDefault="unqualified"
> > attributeFormDefault="unqualified">
> > > > > > > > <xs:include schemaLocation="v2.xsd"/>
> > > > > > > > <xs:include schemaLocation="v3.xsd"/>
> > > > > > > >
> > > > > > > > <xs:complexType name="people">
> > > > > > > > <xs:sequence>
> > > > > > > > <xs:element name="marriedPeople"
> > type="test:marriedPersonName"
> > > > > > > > maxOccurs="unbounded"/>
> > > > > > > > <xs:element name="singlePeople" type="test:personName"
> > > > > > > > maxOccurs="unbounded"/>
> > > > > > > > </xs:sequence>
> > > > > > > > </xs:complexType>
> > > > > > > > <xs:element name="directory" type="test:people"/>
> > > > > > > > </xs:schema>
> > > > > > > >
> > > > > > > > Ed Merks wrote:
> > > > > > > >
> > > > > > > > > James,
> > > > > > > >
> > > > > > > > > I'm not sure I can really answer the details of your
questions
> > > > without
> > > > > > clear
> > > > > > > > > references to particular components in actual schema
documents,
> > > > i.e., a
> > > > > > > > > sample. Perhaps it helps to explain that redefinition is
> > > > accomplished by
> > > > > > > > > making a clone of the schema being redefined and then
modifying
> > that
> > > > copy
> > > > > > > > > according to the redefinition. The original schema is not
> > touched;
> > > > it
> > > > > > may be
> > > > > > > > > redefined many times in many different ways. The schema
> > containing
> > > > the
> > > > > > > > > redefine will see only the copy, not the original. Which
version
> > you
> > > > get
> > > > > > will
> > > > > > > > > depend very much on where you ask, so you need to be
specific...
> > > > > > > >
> > > > > > > > > James Taylor wrote:
> > > > > > > >
> > > > > > > > > > Hello,
> > > > > > > > > > If I understand the W3C spec correctly, a redefined
complexType
> > > > should
> > > > > > be
> > > > > > > > > > used everywhere in place of the original type. For
example,
> > if I
> > > > use
> > > > > > the
> > > > > > > > > > redefined complexType as a base type for another type, the
> > derived
> > > > type
> > > > > > > > > > should now include the additional elements introduced by
the
> > > > redefined
> > > > > > > > > > type. This is not the behavior I'm seeing in Eclipse XSD.
> > When I
> > > > get
> > > > > > the
> > > > > > > > > > base type, using complexTypeDefinition.getBaseType(), I
> > continue
> > > > to get
> > > > > > > > > > the original definition instead of the redefined one.
> > References
> > > > to
> > > > > > the
> > > > > > > > > > type within the schema that has the redefine do point to
the
> > new
> > > > > > redefined
> > > > > > > > > > type, though. Is this intentional? Should I use a
different
> > > > > > mechanism to
> > > > > > > > > > get the base type? Or is this a bug?
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > >
> > > > > > > > > > James
Re: redefine [message #40755 is a reply to message #40108] Fri, 09 April 2004 03:00
 Eclipse User
Originally posted by: jtaylor.nextance.com

Ed,

I believe I found a redefine bug. Complex types that are derived from
types that are redefined continue to pick up the old type definition when
these types are included. For example, in the case I showed below, if
there was a Manager complexType with an Employee base type, the Manager
type when used in the Company.xsd does not pick up the new "rank" element
from the redefinition.

Let me know if you'd rather I just file a bug that post this here. Thanks,

James

Ed Merks wrote:

> James,

> I think you need to show the example I showed below to get a clear answer to
the
> complete question. Multiple different redefines would normally cause a name
> conflict, but not for the example below because the redefines are in
different
> namespaces and hence are redefining different abstract components. Unless
someone
> says the sample below is invalid and can point to some constraint in the
spec that
> would justify an error message for this case, then I will continue to
consider the
> case valid and will not make changes that would make that case stop working.

> The case you show, modified as suggested in the answer to your question at
the
> schema forum, does work correctly now. Do you have cases without redundant
(and
> I'm still convinced, invalid) includes that don't work correctly?

> James Taylor wrote:

> > Ed,
> >
> > Thanks for fixing the bug you found and sorry about the error in
> > Company.xsd. I sent a question to the W3C regarding redefines because I
> > don't think the spec is as clear as it could be, and the answers I
> > received clarify things:
> >
> > http://lists.w3.org/Archives/Public/xmlschema-dev/2004Mar/00 54.html
> >
> > I understand the revised example you've shown below is an alternative,
> > however, it still should work the way I expressed it. The reason this is
> > an important issue for us here at my company is that our schemas can
> > become large with many levels of nesting. Being forced to redefine every
> > encompassing type for all occurrences of a type becomes cumbersome and
> > potentially error prone if an occurrence is missed. It can also prevents
> > being able to redefine a type nested inside of element declaration with an
> > anonymous type.
> >
> > I'll volunteer to fix it if that helps.
> >
> > James
> >
> > Ed Merks wrote:
> > > James,
> >
> > > As I was fixing the Company.xsd to make it valid:
> >
> > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > xmlns:test="http://namespaces.nextance.com/test"
> > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> >
> > > <xs:redefine schemaLocation="Department.xsd">
> > > <xs:complexType name="Employee">
> > > <xs:complexContent>
> > > <xs:extension base="test:Employee">
> > > <xs:sequence>
> > > <xs:element name="ranking" type="xs:int"/>
> > > </xs:sequence>
> > > </xs:extension>
> > > </xs:complexContent>
> > > </xs:complexType>
> > > </xs:redefine>
> >
> > > <xs:complexType name="Company">
> > > <xs:sequence>
> > > <xs:element name="department" type="test:Department"
> > > maxOccurs="unbounded"/>
> > > <xs:element name="president" type="test:Employee"/>
> > > </xs:sequence>
> > > </xs:complexType>
> >
> > > <xs:element name="fortune500" type="test:Company"/>
> >
> > > </xs:schema>
> >
> > > I discovered that there is a bug that causes the transitive
> > includes/redefines of a
> > > cloned included/redefined schema to be omitted so I opened
> > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=56328 and have fixed that
> > particular
> > > problem. So, to my way of thinking, the above sample is the correct way
to
> > express
> > > what you intended.
> >
> > > Consider the following slightly modified example where Employee.xsd has
no
> > > namespace:
> >
> > > <xs:schema
> > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > <xs:complexType name="Employee">
> > > <xs:sequence>
> > > <xs:element name="name" type="xs:string"/>
> > > </xs:sequence>
> > > </xs:complexType>
> > > </xs:schema>
> >
> > > and Department.xsd is still the same (but the include is changing the
null
> > > namespace of the included schema to match that of the including schema):
> >
> > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > xmlns:test="http://namespaces.nextance.com/test"
> > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > <xs:include schemaLocation="Employee.xsd"/>
> >
> > > <xs:complexType name="Department">
> > > <xs:sequence>
> > > <xs:element name="employee" type="test:Employee"
> > > maxOccurs="unbounded"/>
> > > <xs:element name="manager" type="test:Employee"/>
> > > </xs:sequence>
> > > </xs:complexType>
> > > </xs:schema>
> >
> > > In this case, a Company.xsd can validly access both the original version
of
> > > Employee as well as a redefined version.
> >
> > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > xmlns:test="http://namespaces.nextance.com/test"
> > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> >
> > > <xs:import schemaLocation="Employee.xsd"/>
> >
> > > <xs:redefine schemaLocation="Department.xsd">
> > > <xs:complexType name="Employee">
> > > <xs:complexContent>
> > > <xs:extension base="test:Employee">
> > > <xs:sequence>
> > > <xs:element name="ranking" type="xs:int"/>
> > > </xs:sequence>
> > > </xs:extension>
> > > </xs:complexContent>
> > > </xs:complexType>
> > > </xs:redefine>
> >
> > > <xs:complexType name="Company">
> > > <xs:sequence>
> > > <xs:element name="department" type="test:Department"
> > > maxOccurs="unbounded"/>
> > > <xs:element name="president" type="test:Employee"/>
> > > <xs:element name="dummy" type="Employee"/>
> > > </xs:sequence>
> > > </xs:complexType>
> >
> > > <xs:element name="fortune500" type="test:Company"/>
> >
> > > </xs:schema>
> >
> > > The semantics view for this shows that everyone is using the redefined
type,
> > except
> > > the junk element, which is using the original:
> >
> > > [Image]
> >
> > > This stuff is all really much too complicated for human minds to handle
(and
> > I
> > > think there are still lurking bugs in the implementation, but I don't
have
> > any more
> > > time to spend to look at this further).
> >
> > > James Taylor wrote:
> >
> > > > Ed,
> > > >
> > > > Here's a smaller more realistic example that illustrates an issue:
> > > >
> > > > File A defines Employee type
> > > > File B includes File A and defines Department type
> > > > File C includes File B, redefines Employee from File A and defines
Company
> > > > type
> > > >
> > > > This is a common use case for redefine in which a type in a nested
include
> > > > needs to be redefined. With Eclipse XSD, the redefine does not affect
the
> > > > Employee type within the Department type and affects the Employee type
> > > > within the Company type only if the include of File B precedes the
> > > > redefine of File A. This does not seem like the correct behavior.
> > > >
> > > > I've included the XSD files below. Thanks,
> > > >
> > > > James
> > > >
> > > > Employee.xsd:
> > > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > > xmlns:test="http://namespaces.nextance.com/test"
> > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > <xs:complexType name="Employee">
> > > > <xs:sequence>
> > > > <xs:element name="name" type="xs:string"/>
> > > > </xs:sequence>
> > > > </xs:complexType>
> > > > </xs:schema>
> > > >
> > > > Department.xsd:
> > > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > > xmlns:test="http://namespaces.nextance.com/test"
> > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > <xs:include schemaLocation="Employee.xsd"/>
> > > >
> > > > <xs:complexType name="Department">
> > > > <xs:sequence>
> > > > <xs:element name="employee" type="test:Employee"
> > > > maxOccurs="unbounded"/>
> > > > <xs:element name="manager" type="test:Employee"/>
> > > > </xs:sequence>
> > > > </xs:complexType>
> > > > </xs:schema>
> > > >
> > > > Company.xsd:
> > > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > > xmlns:test="http://namespaces.nextance.com/test"
> > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > >
> > > > <xs:include schemaLocation="Department.xsd"/>
> > > >
> > > > <xs:redefine schemaLocation="Employee.xsd">
> > > > <xs:complexType name="Employee">
> > > > <xs:complexContent>
> > > > <xs:extension base="test:Employee">
> > > > <xs:sequence>
> > > > <xs:element name="ranking" type="xs:int"/>
> > > > </xs:sequence>
> > > > </xs:extension>
> > > > </xs:complexContent>
> > > > </xs:complexType>
> > > > </xs:redefine>
> > > >
> > > > <xs:complexType name="Company">
> > > > <xs:sequence>
> > > > <xs:element name="department" type="test:Department"
> > > > maxOccurs="unbounded"/>
> > > > <xs:element name="president" type="test:Employee"/>
> > > > </xs:sequence>
> > > > </xs:complexType>
> > > >
> > > > <xs:element name="fortune500" type="test:Company" maxOccurs="500"/>
> > > >
> > > > </xs:schema>
> > > >
> > > > Ed Merks wrote:
> > > >
> > > > > James,
> > > >
> > > > > All the components of the schema mentioned in the redefine are
> > incorporated
> > > > (i.e.,
> > > > > cloned) and the redefinitions are pervasively applied to all the
> > components
> > > > in that
> > > > > clone. Note that if the schema being redefined has a null target
> > namespace,
> > > > it may
> > > > > be redefined in multiple schemas each with a different namespace and
> > each
> > > > in a
> > > > > different way; in this case, during incorporation, the namespace of
the
> > > > clone is
> > > > > modified to match the namespace of the redefining schema and the
other
> > > > redefinition
> > > > > modifications are applied as well. In any event, the original schema
> > remains
> > > > > untouched so that it can and will be reused in its pristine form when
> > > > referenced
> > > > > directly.
> > > >
> > > > > James Taylor wrote:
> > > >
> > > > > > Ed,
> > > > > >
> > > > > > Thank you for the explanation. It's not clear to me how
"pervasive"
> > the
> > > > > > W3C spec
> > > > > > ( http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#modify-s chema)
> > meant
> > > > > > a redefine to be when they state:
> > > > > >
> > > > > > The modifications have a pervasive impact, that is, only the
> > redefined
> > > > > > components are used, even when referenced from other
incorporated
> > > > > > components, whether redefined themselves or not.
> > > > > >
> > > > > > Given that later in the spec they imply that multiple redefines of
the
> > > > > > same type that conflict are not legal, I assume they meant that the
> > > > > > redefined type should "pervade" everywhere, including in my
example of
> > > > > > v4.xsd.
> > > > > >
> > > > > > James
> > > > > >
> > > > > > Ed Merks wrote:
> > > > > >
> > > > > > > James,
> > > > > >
> > > > > > > The v4.xsd schema isn't valid because its includes both a
redefined
> > > > version
> > > > > > of
> > > > > > > personName and addressee, via its include of v2.xsd's
redefinition of
> > > > > > v1.xsd, as
> > > > > > > well as the original version of personName and addressee, via its
> > > > include of
> > > > > > > v3.xsd's include of v1.xsd without redefinition. The v3.xsd
schema
> > > > needs to
> > > > > > > include v2.xsd not v1.xsd for this example to be valid. The
bottom
> > line
> > > > is
> > > > > > that
> > > > > > > v1.xsd is not modified by virtue of the redefine in v2.xsd; only
> > v2.xsd
> > > > sees
> > > > > > that
> > > > > > > redefinition directly and any schema importing or including
v2.xsd
> > will
> > > > see
> > > > > > that
> > > > > > > redefinition indirectly; but v3.xsd sees only the original
v1.xsd and
> > > > knows
> > > > > > nothing
> > > > > > > of v2.xsd. When we get to v4.xsd, the result is name collision.
> > > > > >
> > > > > > > James Taylor wrote:
> > > > > >
> > > > > > > > Ed,
> > > > > > > >
> > > > > > > > Thanks for the reply. My sample is below. In v4.xsd, I would
have
> > > > > > > > expected that the "marriedPeople" element would contain the
> > > > "generation"
> > > > > > > > element since it is redefined to include this in v2.xsd. The
> > > > > > > > "singlePeople" element does include the "generation" element as
> > > > expected.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > >
> > > > > > > > James
> > > > > > > >
> > > > > > > > v1.xsd:
> > > > > > > > <xs:schema
> > targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > > > elementFormDefault="unqualified"
> > attributeFormDefault="unqualified">
> > > > > > > > <xs:complexType name="personName">
> > > > > > > > <xs:sequence>
> > > > > > > > <xs:element name="title" type="xs:string" minOccurs="0"/>
> > > > > > > > <xs:element name="forename" type="xs:string" minOccurs="0"
> > > > > > > > maxOccurs="unbounded"/>
> > > > > > > > </xs:sequence>
> > > > > > > > </xs:complexType>
> > > > > > > >
> > > > > > > > <xs:element name="addressee" type="test:personName"/>
> > > > > > > > </xs:schema>
> > > > > > > >
> > > > > > > > v2.xsd:
> > > > > > > > <xs:schema
> > targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > > > elementFormDefault="unqualified"
> > attributeFormDefault="unqualified">
> > > > > > > > <xs:redefine schemaLocation="v1.xsd">
> > > > > > > > <xs:complexType name="personName">
> > > > > > > > <xs:complexContent>
> > > > > > > > <xs:extension base="test:personName">
> > > > > > > > <xs:sequence>
> > > > > > > > <xs:element name="generation" type="xs:string"
> > minOccurs="0"/>
> > > > > > > > </xs:sequence>
> > > > > > > > </xs:extension>
> > > > > > > > </xs:complexContent>
> > > > > > > > </xs:complexType>
> > > > > > > > </xs:redefine>
> > > > > > > >
> > > > > > > > <xs:element name="author" type="test:personName"/>
> > > > > > > > </xs:schema>
> > > > > > > >
> > > > > > > > v3.xsd:
> > > > > > > > <xs:schema
> > targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > > > elementFormDefault="unqualified"
> > attributeFormDefault="unqualified">
> > > > > > > > <xs:include schemaLocation="v1.xsd"/>
> > > > > > > >
> > > > > > > > <xs:complexType name="marriedPersonName">
> > > > > > > > <xs:complexContent>
> > > > > > > > <xs:extension base="test:personName">
> > > > > > > > <xs:sequence>
> > > > > > > > <xs:element name="maidenName" type="xs:string"
> > minOccurs="0"/>
> > > > > > > > </xs:sequence>
> > > > > > > > </xs:extension>
> > > > > > > > </xs:complexContent>
> > > > > > > > </xs:complexType>
> > > > > > > >
> > > > > > > > <xs:element name="marriedPerson"
type="test:marriedPersonName"/>
> > > > > > > >
> > > > > > > > </xs:schema>
> > > > > > > >
> > > > > > > > v4.xsd:
> > > > > > > > <xs:schema
> > targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > > > elementFormDefault="unqualified"
> > attributeFormDefault="unqualified">
> > > > > > > > <xs:include schemaLocation="v2.xsd"/>
> > > > > > > > <xs:include schemaLocation="v3.xsd"/>
> > > > > > > >
> > > > > > > > <xs:complexType name="people">
> > > > > > > > <xs:sequence>
> > > > > > > > <xs:element name="marriedPeople"
> > type="test:marriedPersonName"
> > > > > > > > maxOccurs="unbounded"/>
> > > > > > > > <xs:element name="singlePeople" type="test:personName"
> > > > > > > > maxOccurs="unbounded"/>
> > > > > > > > </xs:sequence>
> > > > > > > > </xs:complexType>
> > > > > > > > <xs:element name="directory" type="test:people"/>
> > > > > > > > </xs:schema>
> > > > > > > >
> > > > > > > > Ed Merks wrote:
> > > > > > > >
> > > > > > > > > James,
> > > > > > > >
> > > > > > > > > I'm not sure I can really answer the details of your
questions
> > > > without
> > > > > > clear
> > > > > > > > > references to particular components in actual schema
documents,
> > > > i.e., a
> > > > > > > > > sample. Perhaps it helps to explain that redefinition is
> > > > accomplished by
> > > > > > > > > making a clone of the schema being redefined and then
modifying
> > that
> > > > copy
> > > > > > > > > according to the redefinition. The original schema is not
> > touched;
> > > > it
> > > > > > may be
> > > > > > > > > redefined many times in many different ways. The schema
> > containing
> > > > the
> > > > > > > > > redefine will see only the copy, not the original. Which
version
> > you
> > > > get
> > > > > > will
> > > > > > > > > depend very much on where you ask, so you need to be
specific...
> > > > > > > >
> > > > > > > > > James Taylor wrote:
> > > > > > > >
> > > > > > > > > > Hello,
> > > > > > > > > > If I understand the W3C spec correctly, a redefined
complexType
> > > > should
> > > > > > be
> > > > > > > > > > used everywhere in place of the original type. For
example,
> > if I
> > > > use
> > > > > > the
> > > > > > > > > > redefined complexType as a base type for another type, the
> > derived
> > > > type
> > > > > > > > > > should now include the additional elements introduced by
the
> > > > redefined
> > > > > > > > > > type. This is not the behavior I'm seeing in Eclipse XSD.
> > When I
> > > > get
> > > > > > the
> > > > > > > > > > base type, using complexTypeDefinition.getBaseType(), I
> > continue
> > > > to get
> > > > > > > > > > the original definition instead of the redefined one.
> > References
> > > > to
> > > > > > the
> > > > > > > > > > type within the schema that has the redefine do point to
the
> > new
> > > > > > redefined
> > > > > > > > > > type, though. Is this intentional? Should I use a
different
> > > > > > mechanism to
> > > > > > > > > > get the base type? Or is this a bug?
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > >
> > > > > > > > > > James
Re: redefine [message #40939 is a reply to message #40755] Mon, 12 April 2004 10:44
 Eclipse User
Originally posted by: merks.ca.ibm.com

James,

Please open a bugzilla defect with a sample that illustrates the problem. I
believe that if you redefine a schema document that is composed by including other
schema documents, that the indirectly included documents won't see all the
redefinitions, so I suspect that the problem is avoidable if you put all the
contents into a single schema and redefine that schema.

James Taylor wrote:

> Ed,
>
> I believe I found a redefine bug. Complex types that are derived from
> types that are redefined continue to pick up the old type definition when
> these types are included. For example, in the case I showed below, if
> there was a Manager complexType with an Employee base type, the Manager
> type when used in the Company.xsd does not pick up the new "rank" element
> from the redefinition.
>
> Let me know if you'd rather I just file a bug that post this here. Thanks,
>
> James
>
> Ed Merks wrote:
>
> > James,
>
> > I think you need to show the example I showed below to get a clear answer to
> the
> > complete question. Multiple different redefines would normally cause a name
> > conflict, but not for the example below because the redefines are in
> different
> > namespaces and hence are redefining different abstract components. Unless
> someone
> > says the sample below is invalid and can point to some constraint in the
> spec that
> > would justify an error message for this case, then I will continue to
> consider the
> > case valid and will not make changes that would make that case stop working.
>
> > The case you show, modified as suggested in the answer to your question at
> the
> > schema forum, does work correctly now. Do you have cases without redundant
> (and
> > I'm still convinced, invalid) includes that don't work correctly?
>
> > James Taylor wrote:
>
> > > Ed,
> > >
> > > Thanks for fixing the bug you found and sorry about the error in
> > > Company.xsd. I sent a question to the W3C regarding redefines because I
> > > don't think the spec is as clear as it could be, and the answers I
> > > received clarify things:
> > >
> > > http://lists.w3.org/Archives/Public/xmlschema-dev/2004Mar/00 54.html
> > >
> > > I understand the revised example you've shown below is an alternative,
> > > however, it still should work the way I expressed it. The reason this is
> > > an important issue for us here at my company is that our schemas can
> > > become large with many levels of nesting. Being forced to redefine every
> > > encompassing type for all occurrences of a type becomes cumbersome and
> > > potentially error prone if an occurrence is missed. It can also prevents
> > > being able to redefine a type nested inside of element declaration with an
> > > anonymous type.
> > >
> > > I'll volunteer to fix it if that helps.
> > >
> > > James
> > >
> > > Ed Merks wrote:
> > > > James,
> > >
> > > > As I was fixing the Company.xsd to make it valid:
> > >
> > > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > > xmlns:test="http://namespaces.nextance.com/test"
> > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > >
> > > > <xs:redefine schemaLocation="Department.xsd">
> > > > <xs:complexType name="Employee">
> > > > <xs:complexContent>
> > > > <xs:extension base="test:Employee">
> > > > <xs:sequence>
> > > > <xs:element name="ranking" type="xs:int"/>
> > > > </xs:sequence>
> > > > </xs:extension>
> > > > </xs:complexContent>
> > > > </xs:complexType>
> > > > </xs:redefine>
> > >
> > > > <xs:complexType name="Company">
> > > > <xs:sequence>
> > > > <xs:element name="department" type="test:Department"
> > > > maxOccurs="unbounded"/>
> > > > <xs:element name="president" type="test:Employee"/>
> > > > </xs:sequence>
> > > > </xs:complexType>
> > >
> > > > <xs:element name="fortune500" type="test:Company"/>
> > >
> > > > </xs:schema>
> > >
> > > > I discovered that there is a bug that causes the transitive
> > > includes/redefines of a
> > > > cloned included/redefined schema to be omitted so I opened
> > > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=56328 and have fixed that
> > > particular
> > > > problem. So, to my way of thinking, the above sample is the correct way
> to
> > > express
> > > > what you intended.
> > >
> > > > Consider the following slightly modified example where Employee.xsd has
> no
> > > > namespace:
> > >
> > > > <xs:schema
> > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > <xs:complexType name="Employee">
> > > > <xs:sequence>
> > > > <xs:element name="name" type="xs:string"/>
> > > > </xs:sequence>
> > > > </xs:complexType>
> > > > </xs:schema>
> > >
> > > > and Department.xsd is still the same (but the include is changing the
> null
> > > > namespace of the included schema to match that of the including schema):
> > >
> > > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > > xmlns:test="http://namespaces.nextance.com/test"
> > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > <xs:include schemaLocation="Employee.xsd"/>
> > >
> > > > <xs:complexType name="Department">
> > > > <xs:sequence>
> > > > <xs:element name="employee" type="test:Employee"
> > > > maxOccurs="unbounded"/>
> > > > <xs:element name="manager" type="test:Employee"/>
> > > > </xs:sequence>
> > > > </xs:complexType>
> > > > </xs:schema>
> > >
> > > > In this case, a Company.xsd can validly access both the original version
> of
> > > > Employee as well as a redefined version.
> > >
> > > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > > xmlns:test="http://namespaces.nextance.com/test"
> > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > >
> > > > <xs:import schemaLocation="Employee.xsd"/>
> > >
> > > > <xs:redefine schemaLocation="Department.xsd">
> > > > <xs:complexType name="Employee">
> > > > <xs:complexContent>
> > > > <xs:extension base="test:Employee">
> > > > <xs:sequence>
> > > > <xs:element name="ranking" type="xs:int"/>
> > > > </xs:sequence>
> > > > </xs:extension>
> > > > </xs:complexContent>
> > > > </xs:complexType>
> > > > </xs:redefine>
> > >
> > > > <xs:complexType name="Company">
> > > > <xs:sequence>
> > > > <xs:element name="department" type="test:Department"
> > > > maxOccurs="unbounded"/>
> > > > <xs:element name="president" type="test:Employee"/>
> > > > <xs:element name="dummy" type="Employee"/>
> > > > </xs:sequence>
> > > > </xs:complexType>
> > >
> > > > <xs:element name="fortune500" type="test:Company"/>
> > >
> > > > </xs:schema>
> > >
> > > > The semantics view for this shows that everyone is using the redefined
> type,
> > > except
> > > > the junk element, which is using the original:
> > >
> > > > [Image]
> > >
> > > > This stuff is all really much too complicated for human minds to handle
> (and
> > > I
> > > > think there are still lurking bugs in the implementation, but I don't
> have
> > > any more
> > > > time to spend to look at this further).
> > >
> > > > James Taylor wrote:
> > >
> > > > > Ed,
> > > > >
> > > > > Here's a smaller more realistic example that illustrates an issue:
> > > > >
> > > > > File A defines Employee type
> > > > > File B includes File A and defines Department type
> > > > > File C includes File B, redefines Employee from File A and defines
> Company
> > > > > type
> > > > >
> > > > > This is a common use case for redefine in which a type in a nested
> include
> > > > > needs to be redefined. With Eclipse XSD, the redefine does not affect
> the
> > > > > Employee type within the Department type and affects the Employee type
> > > > > within the Company type only if the include of File B precedes the
> > > > > redefine of File A. This does not seem like the correct behavior.
> > > > >
> > > > > I've included the XSD files below. Thanks,
> > > > >
> > > > > James
> > > > >
> > > > > Employee.xsd:
> > > > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > > > xmlns:test="http://namespaces.nextance.com/test"
> > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > > <xs:complexType name="Employee">
> > > > > <xs:sequence>
> > > > > <xs:element name="name" type="xs:string"/>
> > > > > </xs:sequence>
> > > > > </xs:complexType>
> > > > > </xs:schema>
> > > > >
> > > > > Department.xsd:
> > > > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > > > xmlns:test="http://namespaces.nextance.com/test"
> > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > > <xs:include schemaLocation="Employee.xsd"/>
> > > > >
> > > > > <xs:complexType name="Department">
> > > > > <xs:sequence>
> > > > > <xs:element name="employee" type="test:Employee"
> > > > > maxOccurs="unbounded"/>
> > > > > <xs:element name="manager" type="test:Employee"/>
> > > > > </xs:sequence>
> > > > > </xs:complexType>
> > > > > </xs:schema>
> > > > >
> > > > > Company.xsd:
> > > > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > > > xmlns:test="http://namespaces.nextance.com/test"
> > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > >
> > > > > <xs:include schemaLocation="Department.xsd"/>
> > > > >
> > > > > <xs:redefine schemaLocation="Employee.xsd">
> > > > > <xs:complexType name="Employee">
> > > > > <xs:complexContent>
> > > > > <xs:extension base="test:Employee">
> > > > > <xs:sequence>
> > > > > <xs:element name="ranking" type="xs:int"/>
> > > > > </xs:sequence>
> > > > > </xs:extension>
> > > > > </xs:complexContent>
> > > > > </xs:complexType>
> > > > > </xs:redefine>
> > > > >
> > > > > <xs:complexType name="Company">
> > > > > <xs:sequence>
> > > > > <xs:element name="department" type="test:Department"
> > > > > maxOccurs="unbounded"/>
> > > > > <xs:element name="president" type="test:Employee"/>
> > > > > </xs:sequence>
> > > > > </xs:complexType>
> > > > >
> > > > > <xs:element name="fortune500" type="test:Company" maxOccurs="500"/>
> > > > >
> > > > > </xs:schema>
> > > > >
> > > > > Ed Merks wrote:
> > > > >
> > > > > > James,
> > > > >
> > > > > > All the components of the schema mentioned in the redefine are
> > > incorporated
> > > > > (i.e.,
> > > > > > cloned) and the redefinitions are pervasively applied to all the
> > > components
> > > > > in that
> > > > > > clone. Note that if the schema being redefined has a null target
> > > namespace,
> > > > > it may
> > > > > > be redefined in multiple schemas each with a different namespace and
> > > each
> > > > > in a
> > > > > > different way; in this case, during incorporation, the namespace of
> the
> > > > > clone is
> > > > > > modified to match the namespace of the redefining schema and the
> other
> > > > > redefinition
> > > > > > modifications are applied as well. In any event, the original schema
> > > remains
> > > > > > untouched so that it can and will be reused in its pristine form when
> > > > > referenced
> > > > > > directly.
> > > > >
> > > > > > James Taylor wrote:
> > > > >
> > > > > > > Ed,
> > > > > > >
> > > > > > > Thank you for the explanation. It's not clear to me how
> "pervasive"
> > > the
> > > > > > > W3C spec
> > > > > > > ( http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#modify-s chema)
> > > meant
> > > > > > > a redefine to be when they state:
> > > > > > >
> > > > > > > The modifications have a pervasive impact, that is, only the
> > > redefined
> > > > > > > components are used, even when referenced from other
> incorporated
> > > > > > > components, whether redefined themselves or not.
> > > > > > >
> > > > > > > Given that later in the spec they imply that multiple redefines of
> the
> > > > > > > same type that conflict are not legal, I assume they meant that the
> > > > > > > redefined type should "pervade" everywhere, including in my
> example of
> > > > > > > v4.xsd.
> > > > > > >
> > > > > > > James
> > > > > > >
> > > > > > > Ed Merks wrote:
> > > > > > >
> > > > > > > > James,
> > > > > > >
> > > > > > > > The v4.xsd schema isn't valid because its includes both a
> redefined
> > > > > version
> > > > > > > of
> > > > > > > > personName and addressee, via its include of v2.xsd's
> redefinition of
> > > > > > > v1.xsd, as
> > > > > > > > well as the original version of personName and addressee, via its
> > > > > include of
> > > > > > > > v3.xsd's include of v1.xsd without redefinition. The v3.xsd
> schema
> > > > > needs to
> > > > > > > > include v2.xsd not v1.xsd for this example to be valid. The
> bottom
> > > line
> > > > > is
> > > > > > > that
> > > > > > > > v1.xsd is not modified by virtue of the redefine in v2.xsd; only
> > > v2.xsd
> > > > > sees
> > > > > > > that
> > > > > > > > redefinition directly and any schema importing or including
> v2.xsd
> > > will
> > > > > see
> > > > > > > that
> > > > > > > > redefinition indirectly; but v3.xsd sees only the original
> v1.xsd and
> > > > > knows
> > > > > > > nothing
> > > > > > > > of v2.xsd. When we get to v4.xsd, the result is name collision.
> > > > > > >
> > > > > > > > James Taylor wrote:
> > > > > > >
> > > > > > > > > Ed,
> > > > > > > > >
> > > > > > > > > Thanks for the reply. My sample is below. In v4.xsd, I would
> have
> > > > > > > > > expected that the "marriedPeople" element would contain the
> > > > > "generation"
> > > > > > > > > element since it is redefined to include this in v2.xsd. The
> > > > > > > > > "singlePeople" element does include the "generation" element as
> > > > > expected.
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > >
> > > > > > > > > James
> > > > > > > > >
> > > > > > > > > v1.xsd:
> > > > > > > > > <xs:schema
> > > targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > > > > elementFormDefault="unqualified"
> > > attributeFormDefault="unqualified">
> > > > > > > > > <xs:complexType name="personName">
> > > > > > > > > <xs:sequence>
> > > > > > > > > <xs:element name="title" type="xs:string" minOccurs="0"/>
> > > > > > > > > <xs:element name="forename" type="xs:string" minOccurs="0"
> > > > > > > > > maxOccurs="unbounded"/>
> > > > > > > > > </xs:sequence>
> > > > > > > > > </xs:complexType>
> > > > > > > > >
> > > > > > > > > <xs:element name="addressee" type="test:personName"/>
> > > > > > > > > </xs:schema>
> > > > > > > > >
> > > > > > > > > v2.xsd:
> > > > > > > > > <xs:schema
> > > targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > > > > elementFormDefault="unqualified"
> > > attributeFormDefault="unqualified">
> > > > > > > > > <xs:redefine schemaLocation="v1.xsd">
> > > > > > > > > <xs:complexType name="personName">
> > > > > > > > > <xs:complexContent>
> > > > > > > > > <xs:extension base="test:personName">
> > > > > > > > > <xs:sequence>
> > > > > > > > > <xs:element name="generation" type="xs:string"
> > > minOccurs="0"/>
> > > > > > > > > </xs:sequence>
> > > > > > > > > </xs:extension>
> > > > > > > > > </xs:complexContent>
> > > > > > > > > </xs:complexType>
> > > > > > > > > </xs:redefine>
> > > > > > > > >
> > > > > > > > > <xs:element name="author" type="test:personName"/>
> > > > > > > > > </xs:schema>
> > > > > > > > >
> > > > > > > > > v3.xsd:
> > > > > > > > > <xs:schema
> > > targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > > > > elementFormDefault="unqualified"
> > > attributeFormDefault="unqualified">
> > > > > > > > > <xs:include schemaLocation="v1.xsd"/>
> > > > > > > > >
> > > > > > > > > <xs:complexType name="marriedPersonName">
> > > > > > > > > <xs:complexContent>
> > > > > > > > > <xs:extension base="test:personName">
> > > > > > > > > <xs:sequence>
> > > > > > > > > <xs:element name="maidenName" type="xs:string"
> > > minOccurs="0"/>
> > > > > > > > > </xs:sequence>
> > > > > > > > > </xs:extension>
> > > > > > > > > </xs:complexContent>
> > > > > > > > > </xs:complexType>
> > > > > > > > >
> > > > > > > > > <xs:element name="marriedPerson"
> type="test:marriedPersonName"/>
> > > > > > > > >
> > > > > > > > > </xs:schema>
> > > > > > > > >
> > > > > > > > > v4.xsd:
> > > > > > > > > <xs:schema
> > > targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > > > > elementFormDefault="unqualified"
> > > attributeFormDefault="unqualified">
> > > > > > > > > <xs:include schemaLocation="v2.xsd"/>
> > > > > > > > > <xs:include schemaLocation="v3.xsd"/>
> > > > > > > > >
> > > > > > > > > <xs:complexType name="people">
> > > > > > > > > <xs:sequence>
> > > > > > > > > <xs:element name="marriedPeople"
> > > type="test:marriedPersonName"
> > > > > > > > > maxOccurs="unbounded"/>
> > > > > > > > > <xs:element name="singlePeople" type="test:personName"
> > > > > > > > > maxOccurs="unbounded"/>
> > > > > > > > > </xs:sequence>
> > > > > > > > > </xs:complexType>
> > > > > > > > > <xs:element name="directory" type="test:people"/>
> > > > > > > > > </xs:schema>
> > > > > > > > >
> > > > > > > > > Ed Merks wrote:
> > > > > > > > >
> > > > > > > > > > James,
> > > > > > > > >
> > > > > > > > > > I'm not sure I can really answer the details of your
> questions
> > > > > without
> > > > > > > clear
> > > > > > > > > > references to particular components in actual schema
> documents,
> > > > > i.e., a
> > > > > > > > > > sample. Perhaps it helps to explain that redefinition is
> > > > > accomplished by
> > > > > > > > > > making a clone of the schema being redefined and then
> modifying
> > > that
> > > > > copy
> > > > > > > > > > according to the redefinition. The original schema is not
> > > touched;
> > > > > it
> > > > > > > may be
> > > > > > > > > > redefined many times in many different ways. The schema
> > > containing
> > > > > the
> > > > > > > > > > redefine will see only the copy, not the original. Which
> version
> > > you
> > > > > get
> > > > > > > will
> > > > > > > > > > depend very much on where you ask, so you need to be
> specific...
> > > > > > > > >
> > > > > > > > > > James Taylor wrote:
> > > > > > > > >
> > > > > > > > > > > Hello,
> > > > > > > > > > > If I understand the W3C spec correctly, a redefined
> complexType
> > > > > should
> > > > > > > be
> > > > > > > > > > > used everywhere in place of the original type. For
> example,
> > > if I
> > > > > use
> > > > > > > the
> > > > > > > > > > > redefined complexType as a base type for another type, the
> > > derived
> > > > > type
> > > > > > > > > > > should now include the additional elements introduced by
> the
> > > > > redefined
> > > > > > > > > > > type. This is not the behavior I'm seeing in Eclipse XSD.
> > > When I
> > > > > get
> > > > > > > the
> > > > > > > > > > > base type, using complexTypeDefinition.getBaseType(), I
> > > continue
> > > > > to get
> > > > > > > > > > > the original definition instead of the redefined one.
> > > References
> > > > > to
> > > > > > > the
> > > > > > > > > > > type within the schema that has the redefine do point to
> the
> > > new
> > > > > > > redefined
> > > > > > > > > > > type, though. Is this intentional? Should I use a
> different
> > > > > > > mechanism to
> > > > > > > > > > > get the base type? Or is this a bug?
> > > > > > > > > > >
> > > > > > > > > > > Thanks,
> > > > > > > > > > >
> > > > > > > > > > > James
Re: redefine [message #584509 is a reply to message #39443] Wed, 24 March 2004 00:00
 Ed MerksMessages: 31543Registered: July 2009 Senior Member
James,

I'm not sure I can really answer the details of your questions without clear
references to particular components in actual schema documents, i.e., a
sample. Perhaps it helps to explain that redefinition is accomplished by
making a clone of the schema being redefined and then modifying that copy
according to the redefinition. The original schema is not touched; it may be
redefined many times in many different ways. The schema containing the
redefine will see only the copy, not the original. Which version you get will
depend very much on where you ask, so you need to be specific...

James Taylor wrote:

> Hello,
> If I understand the W3C spec correctly, a redefined complexType should be
> used everywhere in place of the original type. For example, if I use the
> redefined complexType as a base type for another type, the derived type
> should now include the additional elements introduced by the redefined
> type. This is not the behavior I'm seeing in Eclipse XSD. When I get the
> base type, using complexTypeDefinition.getBaseType(), I continue to get
> the original definition instead of the redefined one. References to the
> type within the schema that has the redefine do point to the new redefined
> type, though. Is this intentional? Should I use a different mechanism to
> get the base type? Or is this a bug?
>
> Thanks,
>
> James

Ed Merks
Professional Support: https://www.macromodeling.com/
Re: redefine [message #584530 is a reply to message #39474] Wed, 24 March 2004 00:38
 James TaylorMessages: 21Registered: July 2009 Junior Member
Ed,

Thanks for the reply. My sample is below. In v4.xsd, I would have
expected that the "marriedPeople" element would contain the "generation"
element since it is redefined to include this in v2.xsd. The
"singlePeople" element does include the "generation" element as expected.

Thanks,

James

v1.xsd:
<xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
xmlns:test="http://namespaces.nextance.com/nex/test"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="unqualified" attributeFormDefault="unqualified">
<xs:complexType name="personName">
<xs:sequence>
<xs:element name="title" type="xs:string" minOccurs="0"/>
<xs:element name="forename" type="xs:string" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>

<xs:element name="addressee" type="test:personName"/>
</xs:schema>

v2.xsd:
<xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
xmlns:test="http://namespaces.nextance.com/nex/test"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="unqualified" attributeFormDefault="unqualified">
<xs:redefine schemaLocation="v1.xsd">
<xs:complexType name="personName">
<xs:complexContent>
<xs:extension base="test:personName">
<xs:sequence>
<xs:element name="generation" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:redefine>

<xs:element name="author" type="test:personName"/>
</xs:schema>

v3.xsd:
<xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
xmlns:test="http://namespaces.nextance.com/nex/test"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="unqualified" attributeFormDefault="unqualified">
<xs:include schemaLocation="v1.xsd"/>

<xs:complexType name="marriedPersonName">
<xs:complexContent>
<xs:extension base="test:personName">
<xs:sequence>
<xs:element name="maidenName" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>

<xs:element name="marriedPerson" type="test:marriedPersonName"/>

</xs:schema>

v4.xsd:
<xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
xmlns:test="http://namespaces.nextance.com/nex/test"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="unqualified" attributeFormDefault="unqualified">
<xs:include schemaLocation="v2.xsd"/>
<xs:include schemaLocation="v3.xsd"/>

<xs:complexType name="people">
<xs:sequence>
<xs:element name="marriedPeople" type="test:marriedPersonName"
maxOccurs="unbounded"/>
<xs:element name="singlePeople" type="test:personName"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:element name="directory" type="test:people"/>
</xs:schema>

Ed Merks wrote:

> James,

> I'm not sure I can really answer the details of your questions without clear
> references to particular components in actual schema documents, i.e., a
> sample. Perhaps it helps to explain that redefinition is accomplished by
> making a clone of the schema being redefined and then modifying that copy
> according to the redefinition. The original schema is not touched; it may be
> redefined many times in many different ways. The schema containing the
> redefine will see only the copy, not the original. Which version you get will
> depend very much on where you ask, so you need to be specific...

> James Taylor wrote:

> > Hello,
> > If I understand the W3C spec correctly, a redefined complexType should be
> > used everywhere in place of the original type. For example, if I use the
> > redefined complexType as a base type for another type, the derived type
> > should now include the additional elements introduced by the redefined
> > type. This is not the behavior I'm seeing in Eclipse XSD. When I get the
> > base type, using complexTypeDefinition.getBaseType(), I continue to get
> > the original definition instead of the redefined one. References to the
> > type within the schema that has the redefine do point to the new redefined
> > type, though. Is this intentional? Should I use a different mechanism to
> > get the base type? Or is this a bug?
> >
> > Thanks,
> >
> > James
Re: redefine [message #584543 is a reply to message #39505] Wed, 24 March 2004 12:57
 Ed MerksMessages: 31543Registered: July 2009 Senior Member
James,

The v4.xsd schema isn't valid because its includes both a redefined version of
personName and addressee, via its include of v2.xsd's redefinition of v1.xsd, as
well as the original version of personName and addressee, via its include of
v3.xsd's include of v1.xsd without redefinition. The v3.xsd schema needs to
include v2.xsd not v1.xsd for this example to be valid. The bottom line is that
v1.xsd is not modified by virtue of the redefine in v2.xsd; only v2.xsd sees that
redefinition directly and any schema importing or including v2.xsd will see that
redefinition indirectly; but v3.xsd sees only the original v1.xsd and knows nothing
of v2.xsd. When we get to v4.xsd, the result is name collision.

James Taylor wrote:

> Ed,
>
> Thanks for the reply. My sample is below. In v4.xsd, I would have
> expected that the "marriedPeople" element would contain the "generation"
> element since it is redefined to include this in v2.xsd. The
> "singlePeople" element does include the "generation" element as expected.
>
> Thanks,
>
> James
>
> v1.xsd:
> <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> xmlns:test="http://namespaces.nextance.com/nex/test"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="unqualified" attributeFormDefault="unqualified">
> <xs:complexType name="personName">
> <xs:sequence>
> <xs:element name="title" type="xs:string" minOccurs="0"/>
> <xs:element name="forename" type="xs:string" minOccurs="0"
> maxOccurs="unbounded"/>
> </xs:sequence>
> </xs:complexType>
>
> <xs:element name="addressee" type="test:personName"/>
> </xs:schema>
>
> v2.xsd:
> <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> xmlns:test="http://namespaces.nextance.com/nex/test"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="unqualified" attributeFormDefault="unqualified">
> <xs:redefine schemaLocation="v1.xsd">
> <xs:complexType name="personName">
> <xs:complexContent>
> <xs:extension base="test:personName">
> <xs:sequence>
> <xs:element name="generation" type="xs:string" minOccurs="0"/>
> </xs:sequence>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
> </xs:redefine>
>
> <xs:element name="author" type="test:personName"/>
> </xs:schema>
>
> v3.xsd:
> <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> xmlns:test="http://namespaces.nextance.com/nex/test"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="unqualified" attributeFormDefault="unqualified">
> <xs:include schemaLocation="v1.xsd"/>
>
> <xs:complexType name="marriedPersonName">
> <xs:complexContent>
> <xs:extension base="test:personName">
> <xs:sequence>
> <xs:element name="maidenName" type="xs:string" minOccurs="0"/>
> </xs:sequence>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
>
> <xs:element name="marriedPerson" type="test:marriedPersonName"/>
>
> </xs:schema>
>
> v4.xsd:
> <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> xmlns:test="http://namespaces.nextance.com/nex/test"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="unqualified" attributeFormDefault="unqualified">
> <xs:include schemaLocation="v2.xsd"/>
> <xs:include schemaLocation="v3.xsd"/>
>
> <xs:complexType name="people">
> <xs:sequence>
> <xs:element name="marriedPeople" type="test:marriedPersonName"
> maxOccurs="unbounded"/>
> <xs:element name="singlePeople" type="test:personName"
> maxOccurs="unbounded"/>
> </xs:sequence>
> </xs:complexType>
> <xs:element name="directory" type="test:people"/>
> </xs:schema>
>
> Ed Merks wrote:
>
> > James,
>
> > I'm not sure I can really answer the details of your questions without clear
> > references to particular components in actual schema documents, i.e., a
> > sample. Perhaps it helps to explain that redefinition is accomplished by
> > making a clone of the schema being redefined and then modifying that copy
> > according to the redefinition. The original schema is not touched; it may be
> > redefined many times in many different ways. The schema containing the
> > redefine will see only the copy, not the original. Which version you get will
> > depend very much on where you ask, so you need to be specific...
>
> > James Taylor wrote:
>
> > > Hello,
> > > If I understand the W3C spec correctly, a redefined complexType should be
> > > used everywhere in place of the original type. For example, if I use the
> > > redefined complexType as a base type for another type, the derived type
> > > should now include the additional elements introduced by the redefined
> > > type. This is not the behavior I'm seeing in Eclipse XSD. When I get the
> > > base type, using complexTypeDefinition.getBaseType(), I continue to get
> > > the original definition instead of the redefined one. References to the
> > > type within the schema that has the redefine do point to the new redefined
> > > type, though. Is this intentional? Should I use a different mechanism to
> > > get the base type? Or is this a bug?
> > >
> > > Thanks,
> > >
> > > James

Ed Merks
Professional Support: https://www.macromodeling.com/
Re: redefine [message #584704 is a reply to message #39536] Thu, 25 March 2004 02:09
 James TaylorMessages: 21Registered: July 2009 Junior Member
Ed,

Thank you for the explanation. It's not clear to me how "pervasive" the
W3C spec
( http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#modify-s chema) meant
a redefine to be when they state:

The modifications have a pervasive impact, that is, only the redefined
components are used, even when referenced from other incorporated
components, whether redefined themselves or not.

Given that later in the spec they imply that multiple redefines of the
same type that conflict are not legal, I assume they meant that the
redefined type should "pervade" everywhere, including in my example of
v4.xsd.

James

Ed Merks wrote:

> James,

> The v4.xsd schema isn't valid because its includes both a redefined version
of
> personName and addressee, via its include of v2.xsd's redefinition of
v1.xsd, as
> well as the original version of personName and addressee, via its include of
> v3.xsd's include of v1.xsd without redefinition. The v3.xsd schema needs to
> include v2.xsd not v1.xsd for this example to be valid. The bottom line is
that
> v1.xsd is not modified by virtue of the redefine in v2.xsd; only v2.xsd sees
that
> redefinition directly and any schema importing or including v2.xsd will see
that
> redefinition indirectly; but v3.xsd sees only the original v1.xsd and knows
nothing
> of v2.xsd. When we get to v4.xsd, the result is name collision.

> James Taylor wrote:

> > Ed,
> >
> > Thanks for the reply. My sample is below. In v4.xsd, I would have
> > expected that the "marriedPeople" element would contain the "generation"
> > element since it is redefined to include this in v2.xsd. The
> > "singlePeople" element does include the "generation" element as expected.
> >
> > Thanks,
> >
> > James
> >
> > v1.xsd:
> > <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> > xmlns:test="http://namespaces.nextance.com/nex/test"
> > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > <xs:complexType name="personName">
> > <xs:sequence>
> > <xs:element name="title" type="xs:string" minOccurs="0"/>
> > <xs:element name="forename" type="xs:string" minOccurs="0"
> > maxOccurs="unbounded"/>
> > </xs:sequence>
> > </xs:complexType>
> >
> > <xs:element name="addressee" type="test:personName"/>
> > </xs:schema>
> >
> > v2.xsd:
> > <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> > xmlns:test="http://namespaces.nextance.com/nex/test"
> > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > <xs:redefine schemaLocation="v1.xsd">
> > <xs:complexType name="personName">
> > <xs:complexContent>
> > <xs:extension base="test:personName">
> > <xs:sequence>
> > <xs:element name="generation" type="xs:string" minOccurs="0"/>
> > </xs:sequence>
> > </xs:extension>
> > </xs:complexContent>
> > </xs:complexType>
> > </xs:redefine>
> >
> > <xs:element name="author" type="test:personName"/>
> > </xs:schema>
> >
> > v3.xsd:
> > <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> > xmlns:test="http://namespaces.nextance.com/nex/test"
> > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > <xs:include schemaLocation="v1.xsd"/>
> >
> > <xs:complexType name="marriedPersonName">
> > <xs:complexContent>
> > <xs:extension base="test:personName">
> > <xs:sequence>
> > <xs:element name="maidenName" type="xs:string" minOccurs="0"/>
> > </xs:sequence>
> > </xs:extension>
> > </xs:complexContent>
> > </xs:complexType>
> >
> > <xs:element name="marriedPerson" type="test:marriedPersonName"/>
> >
> > </xs:schema>
> >
> > v4.xsd:
> > <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> > xmlns:test="http://namespaces.nextance.com/nex/test"
> > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > <xs:include schemaLocation="v2.xsd"/>
> > <xs:include schemaLocation="v3.xsd"/>
> >
> > <xs:complexType name="people">
> > <xs:sequence>
> > <xs:element name="marriedPeople" type="test:marriedPersonName"
> > maxOccurs="unbounded"/>
> > <xs:element name="singlePeople" type="test:personName"
> > maxOccurs="unbounded"/>
> > </xs:sequence>
> > </xs:complexType>
> > <xs:element name="directory" type="test:people"/>
> > </xs:schema>
> >
> > Ed Merks wrote:
> >
> > > James,
> >
> > > I'm not sure I can really answer the details of your questions without
clear
> > > references to particular components in actual schema documents, i.e., a
> > > sample. Perhaps it helps to explain that redefinition is accomplished by
> > > making a clone of the schema being redefined and then modifying that copy
> > > according to the redefinition. The original schema is not touched; it
may be
> > > redefined many times in many different ways. The schema containing the
> > > redefine will see only the copy, not the original. Which version you get
will
> > > depend very much on where you ask, so you need to be specific...
> >
> > > James Taylor wrote:
> >
> > > > Hello,
> > > > If I understand the W3C spec correctly, a redefined complexType should
be
> > > > used everywhere in place of the original type. For example, if I use
the
> > > > redefined complexType as a base type for another type, the derived type
> > > > should now include the additional elements introduced by the redefined
> > > > type. This is not the behavior I'm seeing in Eclipse XSD. When I get
the
> > > > base type, using complexTypeDefinition.getBaseType(), I continue to get
> > > > the original definition instead of the redefined one. References to
the
> > > > type within the schema that has the redefine do point to the new
redefined
> > > > type, though. Is this intentional? Should I use a different
mechanism to
> > > > get the base type? Or is this a bug?
> > > >
> > > > Thanks,
> > > >
> > > > James
Re: redefine [message #584719 is a reply to message #39780] Thu, 25 March 2004 11:37
 Ed MerksMessages: 31543Registered: July 2009 Senior Member
James,

All the components of the schema mentioned in the redefine are incorporated (i.e.,
cloned) and the redefinitions are pervasively applied to all the components in that
clone. Note that if the schema being redefined has a null target namespace, it may
be redefined in multiple schemas each with a different namespace and each in a
different way; in this case, during incorporation, the namespace of the clone is
modified to match the namespace of the redefining schema and the other redefinition
modifications are applied as well. In any event, the original schema remains
untouched so that it can and will be reused in its pristine form when referenced
directly.

James Taylor wrote:

> Ed,
>
> Thank you for the explanation. It's not clear to me how "pervasive" the
> W3C spec
> ( http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#modify-s chema) meant
> a redefine to be when they state:
>
> The modifications have a pervasive impact, that is, only the redefined
> components are used, even when referenced from other incorporated
> components, whether redefined themselves or not.
>
> Given that later in the spec they imply that multiple redefines of the
> same type that conflict are not legal, I assume they meant that the
> redefined type should "pervade" everywhere, including in my example of
> v4.xsd.
>
> James
>
> Ed Merks wrote:
>
> > James,
>
> > The v4.xsd schema isn't valid because its includes both a redefined version
> of
> > personName and addressee, via its include of v2.xsd's redefinition of
> v1.xsd, as
> > well as the original version of personName and addressee, via its include of
> > v3.xsd's include of v1.xsd without redefinition. The v3.xsd schema needs to
> > include v2.xsd not v1.xsd for this example to be valid. The bottom line is
> that
> > v1.xsd is not modified by virtue of the redefine in v2.xsd; only v2.xsd sees
> that
> > redefinition directly and any schema importing or including v2.xsd will see
> that
> > redefinition indirectly; but v3.xsd sees only the original v1.xsd and knows
> nothing
> > of v2.xsd. When we get to v4.xsd, the result is name collision.
>
> > James Taylor wrote:
>
> > > Ed,
> > >
> > > Thanks for the reply. My sample is below. In v4.xsd, I would have
> > > expected that the "marriedPeople" element would contain the "generation"
> > > element since it is redefined to include this in v2.xsd. The
> > > "singlePeople" element does include the "generation" element as expected.
> > >
> > > Thanks,
> > >
> > > James
> > >
> > > v1.xsd:
> > > <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > <xs:complexType name="personName">
> > > <xs:sequence>
> > > <xs:element name="title" type="xs:string" minOccurs="0"/>
> > > <xs:element name="forename" type="xs:string" minOccurs="0"
> > > maxOccurs="unbounded"/>
> > > </xs:sequence>
> > > </xs:complexType>
> > >
> > > <xs:element name="addressee" type="test:personName"/>
> > > </xs:schema>
> > >
> > > v2.xsd:
> > > <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > <xs:redefine schemaLocation="v1.xsd">
> > > <xs:complexType name="personName">
> > > <xs:complexContent>
> > > <xs:extension base="test:personName">
> > > <xs:sequence>
> > > <xs:element name="generation" type="xs:string" minOccurs="0"/>
> > > </xs:sequence>
> > > </xs:extension>
> > > </xs:complexContent>
> > > </xs:complexType>
> > > </xs:redefine>
> > >
> > > <xs:element name="author" type="test:personName"/>
> > > </xs:schema>
> > >
> > > v3.xsd:
> > > <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > <xs:include schemaLocation="v1.xsd"/>
> > >
> > > <xs:complexType name="marriedPersonName">
> > > <xs:complexContent>
> > > <xs:extension base="test:personName">
> > > <xs:sequence>
> > > <xs:element name="maidenName" type="xs:string" minOccurs="0"/>
> > > </xs:sequence>
> > > </xs:extension>
> > > </xs:complexContent>
> > > </xs:complexType>
> > >
> > > <xs:element name="marriedPerson" type="test:marriedPersonName"/>
> > >
> > > </xs:schema>
> > >
> > > v4.xsd:
> > > <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > <xs:include schemaLocation="v2.xsd"/>
> > > <xs:include schemaLocation="v3.xsd"/>
> > >
> > > <xs:complexType name="people">
> > > <xs:sequence>
> > > <xs:element name="marriedPeople" type="test:marriedPersonName"
> > > maxOccurs="unbounded"/>
> > > <xs:element name="singlePeople" type="test:personName"
> > > maxOccurs="unbounded"/>
> > > </xs:sequence>
> > > </xs:complexType>
> > > <xs:element name="directory" type="test:people"/>
> > > </xs:schema>
> > >
> > > Ed Merks wrote:
> > >
> > > > James,
> > >
> > > > I'm not sure I can really answer the details of your questions without
> clear
> > > > references to particular components in actual schema documents, i.e., a
> > > > sample. Perhaps it helps to explain that redefinition is accomplished by
> > > > making a clone of the schema being redefined and then modifying that copy
> > > > according to the redefinition. The original schema is not touched; it
> may be
> > > > redefined many times in many different ways. The schema containing the
> > > > redefine will see only the copy, not the original. Which version you get
> will
> > > > depend very much on where you ask, so you need to be specific...
> > >
> > > > James Taylor wrote:
> > >
> > > > > Hello,
> > > > > If I understand the W3C spec correctly, a redefined complexType should
> be
> > > > > used everywhere in place of the original type. For example, if I use
> the
> > > > > redefined complexType as a base type for another type, the derived type
> > > > > should now include the additional elements introduced by the redefined
> > > > > type. This is not the behavior I'm seeing in Eclipse XSD. When I get
> the
> > > > > base type, using complexTypeDefinition.getBaseType(), I continue to get
> > > > > the original definition instead of the redefined one. References to
> the
> > > > > type within the schema that has the redefine do point to the new
> redefined
> > > > > type, though. Is this intentional? Should I use a different
> mechanism to
> > > > > get the base type? Or is this a bug?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > James

Ed Merks
Professional Support: https://www.macromodeling.com/
Re: redefine [message #584784 is a reply to message #39811] Thu, 25 March 2004 23:50
 James TaylorMessages: 21Registered: July 2009 Junior Member
Ed,

Here's a smaller more realistic example that illustrates an issue:

File A defines Employee type
File B includes File A and defines Department type
File C includes File B, redefines Employee from File A and defines Company
type

This is a common use case for redefine in which a type in a nested include
needs to be redefined. With Eclipse XSD, the redefine does not affect the
Employee type within the Department type and affects the Employee type
within the Company type only if the include of File B precedes the
redefine of File A. This does not seem like the correct behavior.

I've included the XSD files below. Thanks,

James

Employee.xsd:
<xs:schema targetNamespace="http://namespaces.nextance.com/test"
xmlns:test="http://namespaces.nextance.com/test"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="unqualified" attributeFormDefault="unqualified">
<xs:complexType name="Employee">
<xs:sequence>
<xs:element name="name" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:schema>

Department.xsd:
<xs:schema targetNamespace="http://namespaces.nextance.com/test"
xmlns:test="http://namespaces.nextance.com/test"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="unqualified" attributeFormDefault="unqualified">
<xs:include schemaLocation="Employee.xsd"/>

<xs:complexType name="Department">
<xs:sequence>
<xs:element name="employee" type="test:Employee"
maxOccurs="unbounded"/>
<xs:element name="manager" type="test:Employee"/>
</xs:sequence>
</xs:complexType>
</xs:schema>

Company.xsd:
<xs:schema targetNamespace="http://namespaces.nextance.com/test"
xmlns:test="http://namespaces.nextance.com/test"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="unqualified" attributeFormDefault="unqualified">

<xs:include schemaLocation="Department.xsd"/>

<xs:redefine schemaLocation="Employee.xsd">
<xs:complexType name="Employee">
<xs:complexContent>
<xs:extension base="test:Employee">
<xs:sequence>
<xs:element name="ranking" type="xs:int"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:redefine>

<xs:complexType name="Company">
<xs:sequence>
<xs:element name="department" type="test:Department"
maxOccurs="unbounded"/>
<xs:element name="president" type="test:Employee"/>
</xs:sequence>
</xs:complexType>

<xs:element name="fortune500" type="test:Company" maxOccurs="500"/>

</xs:schema>

Ed Merks wrote:

> James,

> All the components of the schema mentioned in the redefine are incorporated
(i.e.,
> cloned) and the redefinitions are pervasively applied to all the components
in that
> clone. Note that if the schema being redefined has a null target namespace,
it may
> be redefined in multiple schemas each with a different namespace and each
in a
> different way; in this case, during incorporation, the namespace of the
clone is
> modified to match the namespace of the redefining schema and the other
redefinition
> modifications are applied as well. In any event, the original schema remains
> untouched so that it can and will be reused in its pristine form when
referenced
> directly.

> James Taylor wrote:

> > Ed,
> >
> > Thank you for the explanation. It's not clear to me how "pervasive" the
> > W3C spec
> > ( http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#modify-s chema) meant
> > a redefine to be when they state:
> >
> > The modifications have a pervasive impact, that is, only the redefined
> > components are used, even when referenced from other incorporated
> > components, whether redefined themselves or not.
> >
> > Given that later in the spec they imply that multiple redefines of the
> > same type that conflict are not legal, I assume they meant that the
> > redefined type should "pervade" everywhere, including in my example of
> > v4.xsd.
> >
> > James
> >
> > Ed Merks wrote:
> >
> > > James,
> >
> > > The v4.xsd schema isn't valid because its includes both a redefined
version
> > of
> > > personName and addressee, via its include of v2.xsd's redefinition of
> > v1.xsd, as
> > > well as the original version of personName and addressee, via its
include of
> > > v3.xsd's include of v1.xsd without redefinition. The v3.xsd schema
needs to
> > > include v2.xsd not v1.xsd for this example to be valid. The bottom line
is
> > that
> > > v1.xsd is not modified by virtue of the redefine in v2.xsd; only v2.xsd
sees
> > that
> > > redefinition directly and any schema importing or including v2.xsd will
see
> > that
> > > redefinition indirectly; but v3.xsd sees only the original v1.xsd and
knows
> > nothing
> > > of v2.xsd. When we get to v4.xsd, the result is name collision.
> >
> > > James Taylor wrote:
> >
> > > > Ed,
> > > >
> > > > Thanks for the reply. My sample is below. In v4.xsd, I would have
> > > > expected that the "marriedPeople" element would contain the
"generation"
> > > > element since it is redefined to include this in v2.xsd. The
> > > > "singlePeople" element does include the "generation" element as
expected.
> > > >
> > > > Thanks,
> > > >
> > > > James
> > > >
> > > > v1.xsd:
> > > > <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > <xs:complexType name="personName">
> > > > <xs:sequence>
> > > > <xs:element name="title" type="xs:string" minOccurs="0"/>
> > > > <xs:element name="forename" type="xs:string" minOccurs="0"
> > > > maxOccurs="unbounded"/>
> > > > </xs:sequence>
> > > > </xs:complexType>
> > > >
> > > > <xs:element name="addressee" type="test:personName"/>
> > > > </xs:schema>
> > > >
> > > > v2.xsd:
> > > > <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > <xs:redefine schemaLocation="v1.xsd">
> > > > <xs:complexType name="personName">
> > > > <xs:complexContent>
> > > > <xs:extension base="test:personName">
> > > > <xs:sequence>
> > > > <xs:element name="generation" type="xs:string" minOccurs="0"/>
> > > > </xs:sequence>
> > > > </xs:extension>
> > > > </xs:complexContent>
> > > > </xs:complexType>
> > > > </xs:redefine>
> > > >
> > > > <xs:element name="author" type="test:personName"/>
> > > > </xs:schema>
> > > >
> > > > v3.xsd:
> > > > <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > <xs:include schemaLocation="v1.xsd"/>
> > > >
> > > > <xs:complexType name="marriedPersonName">
> > > > <xs:complexContent>
> > > > <xs:extension base="test:personName">
> > > > <xs:sequence>
> > > > <xs:element name="maidenName" type="xs:string" minOccurs="0"/>
> > > > </xs:sequence>
> > > > </xs:extension>
> > > > </xs:complexContent>
> > > > </xs:complexType>
> > > >
> > > > <xs:element name="marriedPerson" type="test:marriedPersonName"/>
> > > >
> > > > </xs:schema>
> > > >
> > > > v4.xsd:
> > > > <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > <xs:include schemaLocation="v2.xsd"/>
> > > > <xs:include schemaLocation="v3.xsd"/>
> > > >
> > > > <xs:complexType name="people">
> > > > <xs:sequence>
> > > > <xs:element name="marriedPeople" type="test:marriedPersonName"
> > > > maxOccurs="unbounded"/>
> > > > <xs:element name="singlePeople" type="test:personName"
> > > > maxOccurs="unbounded"/>
> > > > </xs:sequence>
> > > > </xs:complexType>
> > > > <xs:element name="directory" type="test:people"/>
> > > > </xs:schema>
> > > >
> > > > Ed Merks wrote:
> > > >
> > > > > James,
> > > >
> > > > > I'm not sure I can really answer the details of your questions
without
> > clear
> > > > > references to particular components in actual schema documents,
i.e., a
> > > > > sample. Perhaps it helps to explain that redefinition is
accomplished by
> > > > > making a clone of the schema being redefined and then modifying that
copy
> > > > > according to the redefinition. The original schema is not touched;
it
> > may be
> > > > > redefined many times in many different ways. The schema containing
the
> > > > > redefine will see only the copy, not the original. Which version you
get
> > will
> > > > > depend very much on where you ask, so you need to be specific...
> > > >
> > > > > James Taylor wrote:
> > > >
> > > > > > Hello,
> > > > > > If I understand the W3C spec correctly, a redefined complexType
should
> > be
> > > > > > used everywhere in place of the original type. For example, if I
use
> > the
> > > > > > redefined complexType as a base type for another type, the derived
type
> > > > > > should now include the additional elements introduced by the
redefined
> > > > > > type. This is not the behavior I'm seeing in Eclipse XSD. When I
get
> > the
> > > > > > base type, using complexTypeDefinition.getBaseType(), I continue
to get
> > > > > > the original definition instead of the redefined one. References
to
> > the
> > > > > > type within the schema that has the redefine do point to the new
> > redefined
> > > > > > type, though. Is this intentional? Should I use a different
> > mechanism to
> > > > > > get the base type? Or is this a bug?
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > James
Re: redefine [message #584820 is a reply to message #39904] Fri, 26 March 2004 18:27
 Ed MerksMessages: 31543Registered: July 2009 Senior Member
--------------CEEB91C322B38F5CBD2D5836
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

James,

As I was fixing the Company.xsd to make it valid:

<xs:schema targetNamespace="http://namespaces.nextance.com/test"
xmlns:test="http://namespaces.nextance.com/test"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="unqualified" attributeFormDefault="unqualified">

<xs:redefine schemaLocation="Department.xsd">
<xs:complexType name="Employee">
<xs:complexContent>
<xs:extension base="test:Employee">
<xs:sequence>
<xs:element name="ranking" type="xs:int"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:redefine>

<xs:complexType name="Company">
<xs:sequence>
<xs:element name="department" type="test:Department"
maxOccurs="unbounded"/>
<xs:element name="president" type="test:Employee"/>
</xs:sequence>
</xs:complexType>

<xs:element name="fortune500" type="test:Company"/>

</xs:schema>

I discovered that there is a bug that causes the transitive includes/redefines of a
cloned included/redefined schema to be omitted so I opened
https://bugs.eclipse.org/bugs/show_bug.cgi?id=56328 and have fixed that particular
problem. So, to my way of thinking, the above sample is the correct way to express
what you intended.

Consider the following slightly modified example where Employee.xsd has no
namespace:

<xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="unqualified" attributeFormDefault="unqualified">
<xs:complexType name="Employee">
<xs:sequence>
<xs:element name="name" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:schema>

and Department.xsd is still the same (but the include is changing the null
namespace of the included schema to match that of the including schema):

<xs:schema targetNamespace="http://namespaces.nextance.com/test"
xmlns:test="http://namespaces.nextance.com/test"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="unqualified" attributeFormDefault="unqualified">
<xs:include schemaLocation="Employee.xsd"/>

<xs:complexType name="Department">
<xs:sequence>
<xs:element name="employee" type="test:Employee"
maxOccurs="unbounded"/>
<xs:element name="manager" type="test:Employee"/>
</xs:sequence>
</xs:complexType>
</xs:schema>

In this case, a Company.xsd can validly access both the original version of
Employee as well as a redefined version.

<xs:schema targetNamespace="http://namespaces.nextance.com/test"
xmlns:test="http://namespaces.nextance.com/test"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="unqualified" attributeFormDefault="unqualified">

<xs:import schemaLocation="Employee.xsd"/>

<xs:redefine schemaLocation="Department.xsd">
<xs:complexType name="Employee">
<xs:complexContent>
<xs:extension base="test:Employee">
<xs:sequence>
<xs:element name="ranking" type="xs:int"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:redefine>

<xs:complexType name="Company">
<xs:sequence>
<xs:element name="department" type="test:Department"
maxOccurs="unbounded"/>
<xs:element name="president" type="test:Employee"/>
<xs:element name="dummy" type="Employee"/>
</xs:sequence>
</xs:complexType>

<xs:element name="fortune500" type="test:Company"/>

</xs:schema>

The semantics view for this shows that everyone is using the redefined type, except
the junk element, which is using the original:

[Image]

This stuff is all really much too complicated for human minds to handle (and I
think there are still lurking bugs in the implementation, but I don't have any more
time to spend to look at this further).

James Taylor wrote:

> Ed,
>
> Here's a smaller more realistic example that illustrates an issue:
>
> File A defines Employee type
> File B includes File A and defines Department type
> File C includes File B, redefines Employee from File A and defines Company
> type
>
> This is a common use case for redefine in which a type in a nested include
> needs to be redefined. With Eclipse XSD, the redefine does not affect the
> Employee type within the Department type and affects the Employee type
> within the Company type only if the include of File B precedes the
> redefine of File A. This does not seem like the correct behavior.
>
> I've included the XSD files below. Thanks,
>
> James
>
> Employee.xsd:
> <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> xmlns:test="http://namespaces.nextance.com/test"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="unqualified" attributeFormDefault="unqualified">
> <xs:complexType name="Employee">
> <xs:sequence>
> <xs:element name="name" type="xs:string"/>
> </xs:sequence>
> </xs:complexType>
> </xs:schema>
>
> Department.xsd:
> <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> xmlns:test="http://namespaces.nextance.com/test"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="unqualified" attributeFormDefault="unqualified">
> <xs:include schemaLocation="Employee.xsd"/>
>
> <xs:complexType name="Department">
> <xs:sequence>
> <xs:element name="employee" type="test:Employee"
> maxOccurs="unbounded"/>
> <xs:element name="manager" type="test:Employee"/>
> </xs:sequence>
> </xs:complexType>
> </xs:schema>
>
> Company.xsd:
> <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> xmlns:test="http://namespaces.nextance.com/test"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="unqualified" attributeFormDefault="unqualified">
>
> <xs:include schemaLocation="Department.xsd"/>
>
> <xs:redefine schemaLocation="Employee.xsd">
> <xs:complexType name="Employee">
> <xs:complexContent>
> <xs:extension base="test:Employee">
> <xs:sequence>
> <xs:element name="ranking" type="xs:int"/>
> </xs:sequence>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
> </xs:redefine>
>
> <xs:complexType name="Company">
> <xs:sequence>
> <xs:element name="department" type="test:Department"
> maxOccurs="unbounded"/>
> <xs:element name="president" type="test:Employee"/>
> </xs:sequence>
> </xs:complexType>
>
> <xs:element name="fortune500" type="test:Company" maxOccurs="500"/>
>
> </xs:schema>
>
> Ed Merks wrote:
>
> > James,
>
> > All the components of the schema mentioned in the redefine are incorporated
> (i.e.,
> > cloned) and the redefinitions are pervasively applied to all the components
> in that
> > clone. Note that if the schema being redefined has a null target namespace,
> it may
> > be redefined in multiple schemas each with a different namespace and each
> in a
> > different way; in this case, during incorporation, the namespace of the
> clone is
> > modified to match the namespace of the redefining schema and the other
> redefinition
> > modifications are applied as well. In any event, the original schema remains
> > untouched so that it can and will be reused in its pristine form when
> referenced
> > directly.
>
> > James Taylor wrote:
>
> > > Ed,
> > >
> > > Thank you for the explanation. It's not clear to me how "pervasive" the
> > > W3C spec
> > > ( http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#modify-s chema) meant
> > > a redefine to be when they state:
> > >
> > > The modifications have a pervasive impact, that is, only the redefined
> > > components are used, even when referenced from other incorporated
> > > components, whether redefined themselves or not.
> > >
> > > Given that later in the spec they imply that multiple redefines of the
> > > same type that conflict are not legal, I assume they meant that the
> > > redefined type should "pervade" everywhere, including in my example of
> > > v4.xsd.
> > >
> > > James
> > >
> > > Ed Merks wrote:
> > >
> > > > James,
> > >
> > > > The v4.xsd schema isn't valid because its includes both a redefined
> version
> > > of
> > > > personName and addressee, via its include of v2.xsd's redefinition of
> > > v1.xsd, as
> > > > well as the original version of personName and addressee, via its
> include of
> > > > v3.xsd's include of v1.xsd without redefinition. The v3.xsd schema
> needs to
> > > > include v2.xsd not v1.xsd for this example to be valid. The bottom line
> is
> > > that
> > > > v1.xsd is not modified by virtue of the redefine in v2.xsd; only v2.xsd
> sees
> > > that
> > > > redefinition directly and any schema importing or including v2.xsd will
> see
> > > that
> > > > redefinition indirectly; but v3.xsd sees only the original v1.xsd and
> knows
> > > nothing
> > > > of v2.xsd. When we get to v4.xsd, the result is name collision.
> > >
> > > > James Taylor wrote:
> > >
> > > > > Ed,
> > > > >
> > > > > Thanks for the reply. My sample is below. In v4.xsd, I would have
> > > > > expected that the "marriedPeople" element would contain the
> "generation"
> > > > > element since it is redefined to include this in v2.xsd. The
> > > > > "singlePeople" element does include the "generation" element as
> expected.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > James
> > > > >
> > > > > v1.xsd:
> > > > > <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > > <xs:complexType name="personName">
> > > > > <xs:sequence>
> > > > > <xs:element name="title" type="xs:string" minOccurs="0"/>
> > > > > <xs:element name="forename" type="xs:string" minOccurs="0"
> > > > > maxOccurs="unbounded"/>
> > > > > </xs:sequence>
> > > > > </xs:complexType>
> > > > >
> > > > > <xs:element name="addressee" type="test:personName"/>
> > > > > </xs:schema>
> > > > >
> > > > > v2.xsd:
> > > > > <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > > <xs:redefine schemaLocation="v1.xsd">
> > > > > <xs:complexType name="personName">
> > > > > <xs:complexContent>
> > > > > <xs:extension base="test:personName">
> > > > > <xs:sequence>
> > > > > <xs:element name="generation" type="xs:string" minOccurs="0"/>
> > > > > </xs:sequence>
> > > > > </xs:extension>
> > > > > </xs:complexContent>
> > > > > </xs:complexType>
> > > > > </xs:redefine>
> > > > >
> > > > > <xs:element name="author" type="test:personName"/>
> > > > > </xs:schema>
> > > > >
> > > > > v3.xsd:
> > > > > <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > > <xs:include schemaLocation="v1.xsd"/>
> > > > >
> > > > > <xs:complexType name="marriedPersonName">
> > > > > <xs:complexContent>
> > > > > <xs:extension base="test:personName">
> > > > > <xs:sequence>
> > > > > <xs:element name="maidenName" type="xs:string" minOccurs="0"/>
> > > > > </xs:sequence>
> > > > > </xs:extension>
> > > > > </xs:complexContent>
> > > > > </xs:complexType>
> > > > >
> > > > > <xs:element name="marriedPerson" type="test:marriedPersonName"/>
> > > > >
> > > > > </xs:schema>
> > > > >
> > > > > v4.xsd:
> > > > > <xs:schema targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > > <xs:include schemaLocation="v2.xsd"/>
> > > > > <xs:include schemaLocation="v3.xsd"/>
> > > > >
> > > > > <xs:complexType name="people">
> > > > > <xs:sequence>
> > > > > <xs:element name="marriedPeople" type="test:marriedPersonName"
> > > > > maxOccurs="unbounded"/>
> > > > > <xs:element name="singlePeople" type="test:personName"
> > > > > maxOccurs="unbounded"/>
> > > > > </xs:sequence>
> > > > > </xs:complexType>
> > > > > <xs:element name="directory" type="test:people"/>
> > > > > </xs:schema>
> > > > >
> > > > > Ed Merks wrote:
> > > > >
> > > > > > James,
> > > > >
> > > > > > I'm not sure I can really answer the details of your questions
> without
> > > clear
> > > > > > references to particular components in actual schema documents,
> i.e., a
> > > > > > sample. Perhaps it helps to explain that redefinition is
> accomplished by
> > > > > > making a clone of the schema being redefined and then modifying that
> copy
> > > > > > according to the redefinition. The original schema is not touched;
> it
> > > may be
> > > > > > redefined many times in many different ways. The schema containing
> the
> > > > > > redefine will see only the copy, not the original. Which version you
> get
> > > will
> > > > > > depend very much on where you ask, so you need to be specific...
> > > > >
> > > > > > James Taylor wrote:
> > > > >
> > > > > > > Hello,
> > > > > > > If I understand the W3C spec correctly, a redefined complexType
> should
> > > be
> > > > > > > used everywhere in place of the original type. For example, if I
> use
> > > the
> > > > > > > redefined complexType as a base type for another type, the derived
> type
> > > > > > > should now include the additional elements introduced by the
> redefined
> > > > > > > type. This is not the behavior I'm seeing in Eclipse XSD. When I
> get
> > > the
> > > > > > > base type, using complexTypeDefinition.getBaseType(), I continue
> to get
> > > > > > > the original definition instead of the redefined one. References
> to
> > > the
> > > > > > > type within the schema that has the redefine do point to the new
> > > redefined
> > > > > > > type, though. Is this intentional? Should I use a different
> > > mechanism to
> > > > > > > get the base type? Or is this a bug?
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > James

--------------CEEB91C322B38F5CBD2D5836
Content-Type: multipart/related;
boundary="------------57AEC190E1D3D8E73CCE5127"

--------------57AEC190E1D3D8E73CCE5127
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
James,
<p>As I was fixing the Company.xsd to make it valid:
<blockquote><font size=-1>&lt;xs:schema targetNamespace="<A HREF="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</A>"</font>
<br><font size=-1>xmlns:test="<A HREF="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</A>"</font>
<br><font size=-1>xmlns:xs="<A HREF="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</A>"</font>
<br><font size=-1>elementFormDefault="unqualified" attributeFormDefault="unqualified"></font><font size=-1></font>
<p><font size=-1>&nbsp; &lt;xs:redefine schemaLocation="Department.xsd"></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp; &lt;xs:complexType name="Employee"></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:complexContent></font>
<br><font size=-1> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;xs:extension
base="test:Employee"></font>
<br><font size=-1> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
&lt;xs:sequence></font>
<br><font size=-1> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xs:element name="ranking" type="xs:int"/></font>
<br><font size=-1> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
&lt;/xs:sequence></font>
<br><font size=-1> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;/xs:extension></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:complexContent></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp; &lt;/xs:complexType></font>
<br><font size=-1>&nbsp; &lt;/xs:redefine></font><font size=-1></font>
<p><font size=-1>&nbsp; &lt;xs:complexType name="Company"></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp; &lt;xs:sequence></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="department"
type="test:Department" maxOccurs="unbounded"/></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="president"
type="test:Employee"/></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp; &lt;/xs:sequence></font>
<br><font size=-1>&nbsp; &lt;/xs:complexType></font><font size=-1></font>
<p><font size=-1>&nbsp; &lt;xs:element name="fortune500" type="test:Company"/></font><font size=-1></font>
<p><font size=-1>&lt;/xs:schema></font></blockquote>
I discovered that there is a bug that causes the transitive includes/redefines
of a cloned included/redefined schema to be omitted so I opened&nbsp; <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=56328">https://bugs.eclipse.org/bugs/show_bug.cgi?id=56328</a>
and have fixed that particular problem. So, to my way of thinking, the
above sample is the correct way to express what you intended.
<p>Consider the following slightly modified example where Employee.xsd
has no namespace:
<blockquote><font size=-1>&lt;xs:schema</font>
<br><font size=-1>xmlns:xs="<A HREF="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</A>"</font>
<br><font size=-1>elementFormDefault="unqualified" attributeFormDefault="unqualified"></font>
<br><font size=-1>&nbsp; &lt;xs:complexType name="Employee"></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp; &lt;xs:sequence></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="name"
type="xs:string"/></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp; &lt;/xs:sequence></font>
<br><font size=-1>&nbsp; &lt;/xs:complexType></font>
<br><font size=-1>&lt;/xs:schema></font></blockquote>
and Department.xsd is still the same (but the include is changing the null
namespace of the included schema to match that of the including schema):
<blockquote><font size=-1>&lt;xs:schema targetNamespace="<A HREF="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</A>"</font>
<br><font size=-1>xmlns:test="<A HREF="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</A>"</font>
<br><font size=-1>xmlns:xs="<A HREF="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</A>"</font>
<br><font size=-1>elementFormDefault="unqualified" attributeFormDefault="unqualified"></font>
<br><font size=-1>&nbsp; &lt;xs:include schemaLocation="Employee.xsd"/></font><font size=-1></font>
<p><font size=-1>&nbsp; &lt;xs:complexType name="Department"></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp; &lt;xs:sequence></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="employee"
type="test:Employee" maxOccurs="unbounded"/></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="manager"
type="test:Employee"/></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp; &lt;/xs:sequence></font>
<br><font size=-1>&nbsp; &lt;/xs:complexType></font>
<br><font size=-1>&lt;/xs:schema></font></blockquote>
In this case, a Company.xsd can validly access both the original version
of Employee as well as a redefined version.
<blockquote><font size=-1>&lt;xs:schema targetNamespace="<A HREF="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</A>"</font>
<br><font size=-1>xmlns:test="<A HREF="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</A>"</font>
<br><font size=-1>xmlns:xs="<A HREF="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</A>"</font>
<br><font size=-1>elementFormDefault="unqualified" attributeFormDefault="unqualified"></font><font size=-1></font>
<p><font size=-1>&nbsp; &lt;xs:import schemaLocation="Employee.xsd"/></font><font size=-1></font>
<p><font size=-1>&nbsp; &lt;xs:redefine schemaLocation="Department.xsd"></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp; &lt;xs:complexType name="Employee"></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:complexContent></font>
<br><font size=-1> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;xs:extension
base="test:Employee"></font>
<br><font size=-1> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
&lt;xs:sequence></font>
<br><font size=-1> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xs:element name="ranking" type="xs:int"/></font>
<br><font size=-1> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
&lt;/xs:sequence></font>
<br><font size=-1> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;/xs:extension></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:complexContent></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp; &lt;/xs:complexType></font>
<br><font size=-1>&nbsp; &lt;/xs:redefine></font><font size=-1></font>
<p><font size=-1>&nbsp; &lt;xs:complexType name="Company"></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp; &lt;xs:sequence></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="department"
type="test:Department" maxOccurs="unbounded"/></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="president"
type="test:Employee"/></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="dummy"
type="Employee"/></font>
<br><font size=-1>&nbsp;&nbsp;&nbsp; &lt;/xs:sequence></font>
<br><font size=-1>&nbsp; &lt;/xs:complexType></font><font size=-1></font>
<p><font size=-1>&nbsp; &lt;xs:element name="fortune500" type="test:Company"/></font><font size=-1></font>
<p><font size=-1>&lt;/xs:schema></font></blockquote>
The semantics view for this shows that everyone is using the redefined
type, except the junk element, which is using the original:
<blockquote><img SRC="cid:part1.40647602.566D4349@ca.ibm.com" height=771 width=263></blockquote>
This stuff is all really much too complicated for human minds to handle
(and I think there are still lurking bugs in the implementation, but I
don't have any more time to spend to look at this further).
<br>&nbsp;
<p>James Taylor wrote:
<blockquote TYPE=CITE>Ed,
<p>Here's a smaller more realistic example that illustrates an issue:
<p>File A defines Employee type
<br>File B includes File A and defines Department type
<br>File C includes File B, redefines Employee from File A and defines
Company
<br>type
<p>This is a common use case for redefine in which a type in a nested include
<br>needs to be redefined.&nbsp; With Eclipse XSD, the redefine does not
affect the
<br>Employee type within the Department type and affects the Employee type
<br>within the Company type only if the include of File B precedes the
<br>redefine of File A.&nbsp; This does not seem like the correct behavior.
<p>I've included the XSD files below.&nbsp; Thanks,
<p>&nbsp;&nbsp;&nbsp; James
<p>Employee.xsd:
<br>&lt;xs:schema targetNamespace="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>xmlns:test="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>xmlns:xs="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>elementFormDefault="unqualified" attributeFormDefault="unqualified">
<br>&nbsp; &lt;xs:complexType name="Employee">
<br>&nbsp;&nbsp;&nbsp; &lt;xs:sequence>
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="name" type="xs:string"/>
<br>&nbsp;&nbsp;&nbsp; &lt;/xs:sequence>
<br>&nbsp; &lt;/xs:complexType>
<br>&lt;/xs:schema>
<p>Department.xsd:
<br>&lt;xs:schema targetNamespace="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>xmlns:test="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>xmlns:xs="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>elementFormDefault="unqualified" attributeFormDefault="unqualified">
<br>&nbsp; &lt;xs:include schemaLocation="Employee.xsd"/>
<p>&nbsp; &lt;xs:complexType name="Department">
<br>&nbsp;&nbsp;&nbsp; &lt;xs:sequence>
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="employee" type="test:Employee"
<br>maxOccurs="unbounded"/>
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="manager" type="test:Employee"/>
<br>&nbsp;&nbsp;&nbsp; &lt;/xs:sequence>
<br>&nbsp; &lt;/xs:complexType>
<br>&lt;/xs:schema>
<p>Company.xsd:
<br>&lt;xs:schema targetNamespace="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>xmlns:test="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>xmlns:xs="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>elementFormDefault="unqualified" attributeFormDefault="unqualified">
<p>&nbsp; &lt;xs:include schemaLocation="Department.xsd"/>
<p>&nbsp; &lt;xs:redefine schemaLocation="Employee.xsd">
<br>&nbsp;&nbsp;&nbsp; &lt;xs:complexType name="Employee">
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:complexContent>
<br> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;xs:extension base="test:Employee">
<br> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &lt;xs:sequence>
<br> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xs:element name="ranking" type="xs:int"/>
<br> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &lt;/xs:sequence>
<br> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;/xs:extension>
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:complexContent>
<br>&nbsp;&nbsp;&nbsp; &lt;/xs:complexType>
<br>&nbsp; &lt;/xs:redefine>
<p>&nbsp; &lt;xs:complexType name="Company">
<br>&nbsp;&nbsp;&nbsp; &lt;xs:sequence>
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="department" type="test:Department"
<br>maxOccurs="unbounded"/>
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="president" type="test:Employee"/>
<br>&nbsp;&nbsp;&nbsp; &lt;/xs:sequence>
<br>&nbsp; &lt;/xs:complexType>
<p>&nbsp; &lt;xs:element name="fortune500" type="test:Company" maxOccurs="500"/>
<p>&lt;/xs:schema>
<p>Ed Merks wrote:
<p>> James,
<p>> All the components of the schema mentioned in the redefine are incorporated
<br>(i.e.,
<br>> cloned) and the redefinitions are pervasively applied to all the
components
<br>in that
<br>> clone.&nbsp; Note that if the schema being redefined has a null target
namespace,
<br>it may
<br>> be redefined in&nbsp; multiple schemas each with a different namespace
and each
<br>in a
<br>> different way; in this case, during incorporation, the namespace
of the
<br>clone is
<br>> modified to match the namespace of the redefining schema and the
other
<br>redefinition
<br>> modifications are applied as well.&nbsp; In any event, the original
schema remains
<br>> untouched so that it can and will be reused in its pristine form
when
<br>referenced
<br>> directly.
<p>> James Taylor wrote:
<p>> > Ed,
<br>> >
<br>> > Thank you for the explanation.&nbsp; It's not clear to me how "pervasive"
the
<br>> > W3C spec
<br>> > (<a href=" http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#modify-s chema"> http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#modify-s chema</a>)
meant
<br>> > a redefine to be when they state:
<br>> >
<br>> >&nbsp;&nbsp;&nbsp;&nbsp; The modifications have a pervasive impact,
that is, only the redefined
<br>> >&nbsp;&nbsp;&nbsp;&nbsp; components are used, even when referenced
from other incorporated
<br>> >&nbsp;&nbsp;&nbsp;&nbsp; components, whether redefined themselves
or not.
<br>> >
<br>> > Given that later in the spec they imply that multiple redefines
of the
<br>> > same type that conflict are not legal, I assume they meant that
the
<br>> > redefined type should "pervade" everywhere, including in my example
of
<br>> > v4.xsd.
<br>> >
<br>> >&nbsp;&nbsp;&nbsp;&nbsp; James
<br>> >
<br>> > Ed Merks wrote:
<br>> >
<br>> > > James,
<br>> >
<br>> > > The v4.xsd schema isn't valid because its includes both a redefined
<br>version
<br>> > of
<br>> > > personName and addressee, via its include of v2.xsd's redefinition
of
<br>> > v1.xsd, as
<br>> > > well as the original version of personName and addressee, via
its
<br>include of
<br>> > > v3.xsd's include of v1.xsd without redefinition.&nbsp; The v3.xsd
schema
<br>needs to
<br>> > > include v2.xsd not v1.xsd for this example to be valid.&nbsp;
The bottom line
<br>is
<br>> > that
<br>> > > v1.xsd is not modified by virtue of the redefine in v2.xsd; only
v2.xsd
<br>sees
<br>> > that
<br>> > > redefinition directly and any schema importing or including v2.xsd
will
<br>see
<br>> > that
<br>> > > redefinition indirectly; but v3.xsd sees only the original v1.xsd
and
<br>knows
<br>> > nothing
<br>> > > of v2.xsd.&nbsp; When we get to v4.xsd, the result is name collision.
<br>> >
<br>> > > James Taylor wrote:
<br>> >
<br>> > > > Ed,
<br>> > > >
<br>> > > > Thanks for the reply.&nbsp; My sample is below.&nbsp; In v4.xsd,
I would have
<br>> > > > expected that the "marriedPeople" element would contain the
<br>"generation"
<br>> > > > element since it is redefined to include this in v2.xsd.&nbsp;
The
<br>> > > > "singlePeople" element does include the "generation" element
as
<br>expected.
<br>> > > >
<br>> > > > Thanks,
<br>> > > >
<br>> > > >&nbsp;&nbsp;&nbsp;&nbsp; James
<br>> > > >
<br>> > > > v1.xsd:
<br>> > > > &lt;xs:schema targetNamespace="<a href="http://namespaces.nextance.com/nex/test">http://namespaces.nextance.com/nex/test</a>"
<br>> > > > xmlns:test="<a href="http://namespaces.nextance.com/nex/test">http://namespaces.nextance.com/nex/test</a>"
<br>> > > > xmlns:xs="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
<br>> > > >&nbsp; &lt;xs:complexType name="personName">
<br>> > > >&nbsp;&nbsp; &lt;xs:sequence>
<br>> > > >&nbsp;&nbsp;&nbsp; &lt;xs:element name="title" type="xs:string"
minOccurs="0"/>
<br>> > > >&nbsp;&nbsp;&nbsp; &lt;xs:element name="forename" type="xs:string"
minOccurs="0"
<br>> > > > maxOccurs="unbounded"/>
<br>> > > >&nbsp;&nbsp; &lt;/xs:sequence>
<br>> > > >&nbsp; &lt;/xs:complexType>
<br>> > > >
<br>> > > >&nbsp; &lt;xs:element name="addressee" type="test:personName"/>
<br>> > > > &lt;/xs:schema>
<br>> > > >
<br>> > > > v2.xsd:
<br>> > > > &lt;xs:schema targetNamespace="<a href="http://namespaces.nextance.com/nex/test">http://namespaces.nextance.com/nex/test</a>"
<br>> > > > xmlns:test="<a href="http://namespaces.nextance.com/nex/test">http://namespaces.nextance.com/nex/test</a>"
<br>> > > > xmlns:xs="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
<br>> > > >&nbsp; &lt;xs:redefine schemaLocation="v1.xsd">
<br>> > > >&nbsp;&nbsp; &lt;xs:complexType name="personName">
<br>> > > >&nbsp;&nbsp;&nbsp; &lt;xs:complexContent>
<br>> > > >&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:extension base="test:personName">
<br>> > > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:sequence>
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="generation"
type="xs:string" minOccurs="0"/>
<br>> > > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:sequence>
<br>> > > >&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:extension>
<br>> > > >&nbsp;&nbsp;&nbsp; &lt;/xs:complexContent>
<br>> > > >&nbsp;&nbsp; &lt;/xs:complexType>
<br>> > > >&nbsp; &lt;/xs:redefine>
<br>> > > >
<br>> > > >&nbsp; &lt;xs:element name="author" type="test:personName"/>
<br>> > > > &lt;/xs:schema>
<br>> > > >
<br>> > > > v3.xsd:
<br>> > > > &lt;xs:schema targetNamespace="<a href="http://namespaces.nextance.com/nex/test">http://namespaces.nextance.com/nex/test</a>"
<br>> > > > xmlns:test="<a href="http://namespaces.nextance.com/nex/test">http://namespaces.nextance.com/nex/test</a>"
<br>> > > > xmlns:xs="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
<br>> > > >&nbsp; &lt;xs:include schemaLocation="v1.xsd"/>
<br>> > > >
<br>> > > >&nbsp;&nbsp; &lt;xs:complexType name="marriedPersonName">
<br>> > > >&nbsp;&nbsp;&nbsp; &lt;xs:complexContent>
<br>> > > >&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:extension base="test:personName">
<br>> > > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:sequence>
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="maidenName"
type="xs:string" minOccurs="0"/>
<br>> > > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:sequence>
<br>> > > >&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:extension>
<br>> > > >&nbsp;&nbsp;&nbsp; &lt;/xs:complexContent>
<br>> > > >&nbsp;&nbsp; &lt;/xs:complexType>
<br>> > > >
<br>> > > >&nbsp; &lt;xs:element name="marriedPerson" type="test:marriedPersonName"/>
<br>> > > >
<br>> > > > &lt;/xs:schema>
<br>> > > >
<br>> > > > v4.xsd:
<br>> > > > &lt;xs:schema targetNamespace="<a href="http://namespaces.nextance.com/nex/test">http://namespaces.nextance.com/nex/test</a>"
<br>> > > > xmlns:test="<a href="http://namespaces.nextance.com/nex/test">http://namespaces.nextance.com/nex/test</a>"
<br>> > > > xmlns:xs="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
<br>> > > >&nbsp; &lt;xs:include schemaLocation="v2.xsd"/>
<br>> > > >&nbsp; &lt;xs:include schemaLocation="v3.xsd"/>
<br>> > > >
<br>> > > >&nbsp;&nbsp; &lt;xs:complexType name="people">
<br>> > > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:sequence>
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="marriedPeople"
type="test:marriedPersonName"
<br>> > > > maxOccurs="unbounded"/>
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="singlePeople"
type="test:personName"
<br>> > > > maxOccurs="unbounded"/>
<br>> > > >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:sequence>
<br>> > > >&nbsp;&nbsp; &lt;/xs:complexType>
<br>> > > >&nbsp; &lt;xs:element name="directory" type="test:people"/>
<br>> > > > &lt;/xs:schema>
<br>> > > >
<br>> > > > Ed Merks wrote:
<br>> > > >
<br>> > > > > James,
<br>> > > >
<br>> > > > > I'm not sure I can really answer the details of your questions
<br>without
<br>> > clear
<br>> > > > > references to particular components in actual schema documents,
<br>i.e., a
<br>> > > > > sample.&nbsp; Perhaps it helps to explain that redefinition
is
<br>accomplished by
<br>> > > > > making a clone of the schema being redefined and then modifying
that
<br>copy
<br>> > > > > according to the redefinition.&nbsp; The original schema
is not touched;
<br>it
<br>> > may be
<br>> > > > > redefined many times in many different ways. The schema containing
<br>the
<br>> > > > > redefine will see only the copy, not the original. Which
version you
<br>get
<br>> > will
<br>> > > > > depend very much on where you ask, so you need to be specific...
<br>> > > >
<br>> > > > > James Taylor wrote:
<br>> > > >
<br>> > > > > > Hello,
<br>> > > > > > If I understand the W3C spec correctly, a redefined complexType
<br>should
<br>> > be
<br>> > > > > > used everywhere in place of the original type.&nbsp; For
example, if I
<br>use
<br>> > the
<br>> > > > > > redefined complexType as a base type for another type,
the derived
<br>type
<br>> > > > > > should now include the additional elements introduced by
the
<br>redefined
<br>> > > > > > type.&nbsp; This is not the behavior I'm seeing in Eclipse
XSD.&nbsp; When I
<br>get
<br>> > the
<br>> > > > > > base type, using complexTypeDefinition.getBaseType(), I
continue
<br>to get
<br>> > > > > > the original definition instead of the redefined one.&nbsp;
References
<br>to
<br>> > the
<br>> > > > > > type within the schema that has the redefine do point to
the new
<br>> > redefined
<br>> > > > > > type, though.&nbsp; Is this intentional?&nbsp; Should I
use a different
<br>> > mechanism to
<br>> > > > > > get the base type?&nbsp; Or is this a bug?
<br>> > > > > >
<br>> > > > > > Thanks,
<br>> > > > > >
<br>> > > > > >&nbsp;&nbsp;&nbsp;&nbsp; James</blockquote>
</html>

--------------57AEC190E1D3D8E73CCE5127
Content-Type: image/jpeg
Content-ID: <part1.40647602.566D4349@ca.ibm.com>
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\nsmailC1.jpeg"

/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDACAWGBwYFCAcGhwkIiAmMFA0MCws MGJGSjpQdGZ6
eHJmcG6AkLicgIiuim5woNqirr7EztDOfJri8uDI8LjKzsb/2wBDASIkJDAq MF40NF7GhHCE
xsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbG xsbGxsb/wAAR
CAMDAQcDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcI CQoL/8QAtRAA
AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS 0fAkM2JyggkK
FhcYGRolJicoKSo0NT

Ed Merks
Professional Support: https://www.macromodeling.com/
Re: redefine [message #584855 is a reply to message #39976] Mon, 29 March 2004 22:56
 James TaylorMessages: 21Registered: July 2009 Junior Member
Ed,

Thanks for fixing the bug you found and sorry about the error in
Company.xsd. I sent a question to the W3C regarding redefines because I
don't think the spec is as clear as it could be, and the answers I
received clarify things:

http://lists.w3.org/Archives/Public/xmlschema-dev/2004Mar/00 54.html

I understand the revised example you've shown below is an alternative,
however, it still should work the way I expressed it. The reason this is
an important issue for us here at my company is that our schemas can
become large with many levels of nesting. Being forced to redefine every
encompassing type for all occurrences of a type becomes cumbersome and
potentially error prone if an occurrence is missed. It can also prevents
being able to redefine a type nested inside of element declaration with an
anonymous type.

I'll volunteer to fix it if that helps.

James

Ed Merks wrote:
> James,

> As I was fixing the Company.xsd to make it valid:

> <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> xmlns:test="http://namespaces.nextance.com/test"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="unqualified" attributeFormDefault="unqualified">

> <xs:redefine schemaLocation="Department.xsd">
> <xs:complexType name="Employee">
> <xs:complexContent>
> <xs:extension base="test:Employee">
> <xs:sequence>
> <xs:element name="ranking" type="xs:int"/>
> </xs:sequence>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
> </xs:redefine>

> <xs:complexType name="Company">
> <xs:sequence>
> <xs:element name="department" type="test:Department"
> maxOccurs="unbounded"/>
> <xs:element name="president" type="test:Employee"/>
> </xs:sequence>
> </xs:complexType>

> <xs:element name="fortune500" type="test:Company"/>

> </xs:schema>

> I discovered that there is a bug that causes the transitive
includes/redefines of a
> cloned included/redefined schema to be omitted so I opened
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=56328 and have fixed that
particular
> problem. So, to my way of thinking, the above sample is the correct way to
express
> what you intended.

> Consider the following slightly modified example where Employee.xsd has no
> namespace:

> <xs:schema
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="unqualified" attributeFormDefault="unqualified">
> <xs:complexType name="Employee">
> <xs:sequence>
> <xs:element name="name" type="xs:string"/>
> </xs:sequence>
> </xs:complexType>
> </xs:schema>

> and Department.xsd is still the same (but the include is changing the null
> namespace of the included schema to match that of the including schema):

> <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> xmlns:test="http://namespaces.nextance.com/test"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="unqualified" attributeFormDefault="unqualified">
> <xs:include schemaLocation="Employee.xsd"/>

> <xs:complexType name="Department">
> <xs:sequence>
> <xs:element name="employee" type="test:Employee"
> maxOccurs="unbounded"/>
> <xs:element name="manager" type="test:Employee"/>
> </xs:sequence>
> </xs:complexType>
> </xs:schema>

> In this case, a Company.xsd can validly access both the original version of
> Employee as well as a redefined version.

> <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> xmlns:test="http://namespaces.nextance.com/test"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="unqualified" attributeFormDefault="unqualified">

> <xs:import schemaLocation="Employee.xsd"/>

> <xs:redefine schemaLocation="Department.xsd">
> <xs:complexType name="Employee">
> <xs:complexContent>
> <xs:extension base="test:Employee">
> <xs:sequence>
> <xs:element name="ranking" type="xs:int"/>
> </xs:sequence>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
> </xs:redefine>

> <xs:complexType name="Company">
> <xs:sequence>
> <xs:element name="department" type="test:Department"
> maxOccurs="unbounded"/>
> <xs:element name="president" type="test:Employee"/>
> <xs:element name="dummy" type="Employee"/>
> </xs:sequence>
> </xs:complexType>

> <xs:element name="fortune500" type="test:Company"/>

> </xs:schema>

> The semantics view for this shows that everyone is using the redefined type,
except
> the junk element, which is using the original:

> [Image]

> This stuff is all really much too complicated for human minds to handle (and
I
> think there are still lurking bugs in the implementation, but I don't have
any more
> time to spend to look at this further).

> James Taylor wrote:

> > Ed,
> >
> > Here's a smaller more realistic example that illustrates an issue:
> >
> > File A defines Employee type
> > File B includes File A and defines Department type
> > File C includes File B, redefines Employee from File A and defines Company
> > type
> >
> > This is a common use case for redefine in which a type in a nested include
> > needs to be redefined. With Eclipse XSD, the redefine does not affect the
> > Employee type within the Department type and affects the Employee type
> > within the Company type only if the include of File B precedes the
> > redefine of File A. This does not seem like the correct behavior.
> >
> > I've included the XSD files below. Thanks,
> >
> > James
> >
> > Employee.xsd:
> > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > xmlns:test="http://namespaces.nextance.com/test"
> > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > <xs:complexType name="Employee">
> > <xs:sequence>
> > <xs:element name="name" type="xs:string"/>
> > </xs:sequence>
> > </xs:complexType>
> > </xs:schema>
> >
> > Department.xsd:
> > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > xmlns:test="http://namespaces.nextance.com/test"
> > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > <xs:include schemaLocation="Employee.xsd"/>
> >
> > <xs:complexType name="Department">
> > <xs:sequence>
> > <xs:element name="employee" type="test:Employee"
> > maxOccurs="unbounded"/>
> > <xs:element name="manager" type="test:Employee"/>
> > </xs:sequence>
> > </xs:complexType>
> > </xs:schema>
> >
> > Company.xsd:
> > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > xmlns:test="http://namespaces.nextance.com/test"
> > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> >
> > <xs:include schemaLocation="Department.xsd"/>
> >
> > <xs:redefine schemaLocation="Employee.xsd">
> > <xs:complexType name="Employee">
> > <xs:complexContent>
> > <xs:extension base="test:Employee">
> > <xs:sequence>
> > <xs:element name="ranking" type="xs:int"/>
> > </xs:sequence>
> > </xs:extension>
> > </xs:complexContent>
> > </xs:complexType>
> > </xs:redefine>
> >
> > <xs:complexType name="Company">
> > <xs:sequence>
> > <xs:element name="department" type="test:Department"
> > maxOccurs="unbounded"/>
> > <xs:element name="president" type="test:Employee"/>
> > </xs:sequence>
> > </xs:complexType>
> >
> > <xs:element name="fortune500" type="test:Company" maxOccurs="500"/>
> >
> > </xs:schema>
> >
> > Ed Merks wrote:
> >
> > > James,
> >
> > > All the components of the schema mentioned in the redefine are
incorporated
> > (i.e.,
> > > cloned) and the redefinitions are pervasively applied to all the
components
> > in that
> > > clone. Note that if the schema being redefined has a null target
namespace,
> > it may
> > > be redefined in multiple schemas each with a different namespace and
each
> > in a
> > > different way; in this case, during incorporation, the namespace of the
> > clone is
> > > modified to match the namespace of the redefining schema and the other
> > redefinition
> > > modifications are applied as well. In any event, the original schema
remains
> > > untouched so that it can and will be reused in its pristine form when
> > referenced
> > > directly.
> >
> > > James Taylor wrote:
> >
> > > > Ed,
> > > >
> > > > Thank you for the explanation. It's not clear to me how "pervasive"
the
> > > > W3C spec
> > > > ( http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#modify-s chema)
meant
> > > > a redefine to be when they state:
> > > >
> > > > The modifications have a pervasive impact, that is, only the
redefined
> > > > components are used, even when referenced from other incorporated
> > > > components, whether redefined themselves or not.
> > > >
> > > > Given that later in the spec they imply that multiple redefines of the
> > > > same type that conflict are not legal, I assume they meant that the
> > > > redefined type should "pervade" everywhere, including in my example of
> > > > v4.xsd.
> > > >
> > > > James
> > > >
> > > > Ed Merks wrote:
> > > >
> > > > > James,
> > > >
> > > > > The v4.xsd schema isn't valid because its includes both a redefined
> > version
> > > > of
> > > > > personName and addressee, via its include of v2.xsd's redefinition of
> > > > v1.xsd, as
> > > > > well as the original version of personName and addressee, via its
> > include of
> > > > > v3.xsd's include of v1.xsd without redefinition. The v3.xsd schema
> > needs to
> > > > > include v2.xsd not v1.xsd for this example to be valid. The bottom
line
> > is
> > > > that
> > > > > v1.xsd is not modified by virtue of the redefine in v2.xsd; only
v2.xsd
> > sees
> > > > that
> > > > > redefinition directly and any schema importing or including v2.xsd
will
> > see
> > > > that
> > > > > redefinition indirectly; but v3.xsd sees only the original v1.xsd and
> > knows
> > > > nothing
> > > > > of v2.xsd. When we get to v4.xsd, the result is name collision.
> > > >
> > > > > James Taylor wrote:
> > > >
> > > > > > Ed,
> > > > > >
> > > > > > Thanks for the reply. My sample is below. In v4.xsd, I would have
> > > > > > expected that the "marriedPeople" element would contain the
> > "generation"
> > > > > > element since it is redefined to include this in v2.xsd. The
> > > > > > "singlePeople" element does include the "generation" element as
> > expected.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > James
> > > > > >
> > > > > > v1.xsd:
> > > > > > <xs:schema
targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > elementFormDefault="unqualified"
attributeFormDefault="unqualified">
> > > > > > <xs:complexType name="personName">
> > > > > > <xs:sequence>
> > > > > > <xs:element name="title" type="xs:string" minOccurs="0"/>
> > > > > > <xs:element name="forename" type="xs:string" minOccurs="0"
> > > > > > maxOccurs="unbounded"/>
> > > > > > </xs:sequence>
> > > > > > </xs:complexType>
> > > > > >
> > > > > > <xs:element name="addressee" type="test:personName"/>
> > > > > > </xs:schema>
> > > > > >
> > > > > > v2.xsd:
> > > > > > <xs:schema
targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > elementFormDefault="unqualified"
attributeFormDefault="unqualified">
> > > > > > <xs:redefine schemaLocation="v1.xsd">
> > > > > > <xs:complexType name="personName">
> > > > > > <xs:complexContent>
> > > > > > <xs:extension base="test:personName">
> > > > > > <xs:sequence>
> > > > > > <xs:element name="generation" type="xs:string"
minOccurs="0"/>
> > > > > > </xs:sequence>
> > > > > > </xs:extension>
> > > > > > </xs:complexContent>
> > > > > > </xs:complexType>
> > > > > > </xs:redefine>
> > > > > >
> > > > > > <xs:element name="author" type="test:personName"/>
> > > > > > </xs:schema>
> > > > > >
> > > > > > v3.xsd:
> > > > > > <xs:schema
targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > elementFormDefault="unqualified"
attributeFormDefault="unqualified">
> > > > > > <xs:include schemaLocation="v1.xsd"/>
> > > > > >
> > > > > > <xs:complexType name="marriedPersonName">
> > > > > > <xs:complexContent>
> > > > > > <xs:extension base="test:personName">
> > > > > > <xs:sequence>
> > > > > > <xs:element name="maidenName" type="xs:string"
minOccurs="0"/>
> > > > > > </xs:sequence>
> > > > > > </xs:extension>
> > > > > > </xs:complexContent>
> > > > > > </xs:complexType>
> > > > > >
> > > > > > <xs:element name="marriedPerson" type="test:marriedPersonName"/>
> > > > > >
> > > > > > </xs:schema>
> > > > > >
> > > > > > v4.xsd:
> > > > > > <xs:schema
targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > elementFormDefault="unqualified"
attributeFormDefault="unqualified">
> > > > > > <xs:include schemaLocation="v2.xsd"/>
> > > > > > <xs:include schemaLocation="v3.xsd"/>
> > > > > >
> > > > > > <xs:complexType name="people">
> > > > > > <xs:sequence>
> > > > > > <xs:element name="marriedPeople"
type="test:marriedPersonName"
> > > > > > maxOccurs="unbounded"/>
> > > > > > <xs:element name="singlePeople" type="test:personName"
> > > > > > maxOccurs="unbounded"/>
> > > > > > </xs:sequence>
> > > > > > </xs:complexType>
> > > > > > <xs:element name="directory" type="test:people"/>
> > > > > > </xs:schema>
> > > > > >
> > > > > > Ed Merks wrote:
> > > > > >
> > > > > > > James,
> > > > > >
> > > > > > > I'm not sure I can really answer the details of your questions
> > without
> > > > clear
> > > > > > > references to particular components in actual schema documents,
> > i.e., a
> > > > > > > sample. Perhaps it helps to explain that redefinition is
> > accomplished by
> > > > > > > making a clone of the schema being redefined and then modifying
that
> > copy
> > > > > > > according to the redefinition. The original schema is not
touched;
> > it
> > > > may be
> > > > > > > redefined many times in many different ways. The schema
containing
> > the
> > > > > > > redefine will see only the copy, not the original. Which version
you
> > get
> > > > will
> > > > > > > depend very much on where you ask, so you need to be specific...
> > > > > >
> > > > > > > James Taylor wrote:
> > > > > >
> > > > > > > > Hello,
> > > > > > > > If I understand the W3C spec correctly, a redefined complexType
> > should
> > > > be
> > > > > > > > used everywhere in place of the original type. For example,
if I
> > use
> > > > the
> > > > > > > > redefined complexType as a base type for another type, the
derived
> > type
> > > > > > > > should now include the additional elements introduced by the
> > redefined
> > > > > > > > type. This is not the behavior I'm seeing in Eclipse XSD.
When I
> > get
> > > > the
> > > > > > > > base type, using complexTypeDefinition.getBaseType(), I
continue
> > to get
> > > > > > > > the original definition instead of the redefined one.
References
> > to
> > > > the
> > > > > > > > type within the schema that has the redefine do point to the
new
> > > > redefined
> > > > > > > > type, though. Is this intentional? Should I use a different
> > > > mechanism to
> > > > > > > > get the base type? Or is this a bug?
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > >
> > > > > > > > James
Re: redefine [message #584887 is a reply to message #40038] Tue, 30 March 2004 11:28
 Ed MerksMessages: 31543Registered: July 2009 Senior Member
--------------CB5C521ADEF6460EF290FC80
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

James,

I think you need to show the example I showed below to get a clear answer to the
complete question. Multiple different redefines would normally cause a name
conflict, but not for the example below because the redefines are in different
namespaces and hence are redefining different abstract components. Unless someone
says the sample below is invalid and can point to some constraint in the spec that
would justify an error message for this case, then I will continue to consider the
case valid and will not make changes that would make that case stop working.

The case you show, modified as suggested in the answer to your question at the
schema forum, does work correctly now. Do you have cases without redundant (and
I'm still convinced, invalid) includes that don't work correctly?

James Taylor wrote:

> Ed,
>
> Thanks for fixing the bug you found and sorry about the error in
> Company.xsd. I sent a question to the W3C regarding redefines because I
> don't think the spec is as clear as it could be, and the answers I
> received clarify things:
>
> http://lists.w3.org/Archives/Public/xmlschema-dev/2004Mar/00 54.html
>
> I understand the revised example you've shown below is an alternative,
> however, it still should work the way I expressed it. The reason this is
> an important issue for us here at my company is that our schemas can
> become large with many levels of nesting. Being forced to redefine every
> encompassing type for all occurrences of a type becomes cumbersome and
> potentially error prone if an occurrence is missed. It can also prevents
> being able to redefine a type nested inside of element declaration with an
> anonymous type.
>
> I'll volunteer to fix it if that helps.
>
> James
>
> Ed Merks wrote:
> > James,
>
> > As I was fixing the Company.xsd to make it valid:
>
> > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > xmlns:test="http://namespaces.nextance.com/test"
> > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > elementFormDefault="unqualified" attributeFormDefault="unqualified">
>
> > <xs:redefine schemaLocation="Department.xsd">
> > <xs:complexType name="Employee">
> > <xs:complexContent>
> > <xs:extension base="test:Employee">
> > <xs:sequence>
> > <xs:element name="ranking" type="xs:int"/>
> > </xs:sequence>
> > </xs:extension>
> > </xs:complexContent>
> > </xs:complexType>
> > </xs:redefine>
>
> > <xs:complexType name="Company">
> > <xs:sequence>
> > <xs:element name="department" type="test:Department"
> > maxOccurs="unbounded"/>
> > <xs:element name="president" type="test:Employee"/>
> > </xs:sequence>
> > </xs:complexType>
>
> > <xs:element name="fortune500" type="test:Company"/>
>
> > </xs:schema>
>
> > I discovered that there is a bug that causes the transitive
> includes/redefines of a
> > cloned included/redefined schema to be omitted so I opened
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=56328 and have fixed that
> particular
> > problem. So, to my way of thinking, the above sample is the correct way to
> express
> > what you intended.
>
> > Consider the following slightly modified example where Employee.xsd has no
> > namespace:
>
> > <xs:schema
> > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > <xs:complexType name="Employee">
> > <xs:sequence>
> > <xs:element name="name" type="xs:string"/>
> > </xs:sequence>
> > </xs:complexType>
> > </xs:schema>
>
> > and Department.xsd is still the same (but the include is changing the null
> > namespace of the included schema to match that of the including schema):
>
> > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > xmlns:test="http://namespaces.nextance.com/test"
> > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > <xs:include schemaLocation="Employee.xsd"/>
>
> > <xs:complexType name="Department">
> > <xs:sequence>
> > <xs:element name="employee" type="test:Employee"
> > maxOccurs="unbounded"/>
> > <xs:element name="manager" type="test:Employee"/>
> > </xs:sequence>
> > </xs:complexType>
> > </xs:schema>
>
> > In this case, a Company.xsd can validly access both the original version of
> > Employee as well as a redefined version.
>
> > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > xmlns:test="http://namespaces.nextance.com/test"
> > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > elementFormDefault="unqualified" attributeFormDefault="unqualified">
>
> > <xs:import schemaLocation="Employee.xsd"/>
>
> > <xs:redefine schemaLocation="Department.xsd">
> > <xs:complexType name="Employee">
> > <xs:complexContent>
> > <xs:extension base="test:Employee">
> > <xs:sequence>
> > <xs:element name="ranking" type="xs:int"/>
> > </xs:sequence>
> > </xs:extension>
> > </xs:complexContent>
> > </xs:complexType>
> > </xs:redefine>
>
> > <xs:complexType name="Company">
> > <xs:sequence>
> > <xs:element name="department" type="test:Department"
> > maxOccurs="unbounded"/>
> > <xs:element name="president" type="test:Employee"/>
> > <xs:element name="dummy" type="Employee"/>
> > </xs:sequence>
> > </xs:complexType>
>
> > <xs:element name="fortune500" type="test:Company"/>
>
> > </xs:schema>
>
> > The semantics view for this shows that everyone is using the redefined type,
> except
> > the junk element, which is using the original:
>
> > [Image]
>
> > This stuff is all really much too complicated for human minds to handle (and
> I
> > think there are still lurking bugs in the implementation, but I don't have
> any more
> > time to spend to look at this further).
>
> > James Taylor wrote:
>
> > > Ed,
> > >
> > > Here's a smaller more realistic example that illustrates an issue:
> > >
> > > File A defines Employee type
> > > File B includes File A and defines Department type
> > > File C includes File B, redefines Employee from File A and defines Company
> > > type
> > >
> > > This is a common use case for redefine in which a type in a nested include
> > > needs to be redefined. With Eclipse XSD, the redefine does not affect the
> > > Employee type within the Department type and affects the Employee type
> > > within the Company type only if the include of File B precedes the
> > > redefine of File A. This does not seem like the correct behavior.
> > >
> > > I've included the XSD files below. Thanks,
> > >
> > > James
> > >
> > > Employee.xsd:
> > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > xmlns:test="http://namespaces.nextance.com/test"
> > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > <xs:complexType name="Employee">
> > > <xs:sequence>
> > > <xs:element name="name" type="xs:string"/>
> > > </xs:sequence>
> > > </xs:complexType>
> > > </xs:schema>
> > >
> > > Department.xsd:
> > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > xmlns:test="http://namespaces.nextance.com/test"
> > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > <xs:include schemaLocation="Employee.xsd"/>
> > >
> > > <xs:complexType name="Department">
> > > <xs:sequence>
> > > <xs:element name="employee" type="test:Employee"
> > > maxOccurs="unbounded"/>
> > > <xs:element name="manager" type="test:Employee"/>
> > > </xs:sequence>
> > > </xs:complexType>
> > > </xs:schema>
> > >
> > > Company.xsd:
> > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > xmlns:test="http://namespaces.nextance.com/test"
> > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > >
> > > <xs:include schemaLocation="Department.xsd"/>
> > >
> > > <xs:redefine schemaLocation="Employee.xsd">
> > > <xs:complexType name="Employee">
> > > <xs:complexContent>
> > > <xs:extension base="test:Employee">
> > > <xs:sequence>
> > > <xs:element name="ranking" type="xs:int"/>
> > > </xs:sequence>
> > > </xs:extension>
> > > </xs:complexContent>
> > > </xs:complexType>
> > > </xs:redefine>
> > >
> > > <xs:complexType name="Company">
> > > <xs:sequence>
> > > <xs:element name="department" type="test:Department"
> > > maxOccurs="unbounded"/>
> > > <xs:element name="president" type="test:Employee"/>
> > > </xs:sequence>
> > > </xs:complexType>
> > >
> > > <xs:element name="fortune500" type="test:Company" maxOccurs="500"/>
> > >
> > > </xs:schema>
> > >
> > > Ed Merks wrote:
> > >
> > > > James,
> > >
> > > > All the components of the schema mentioned in the redefine are
> incorporated
> > > (i.e.,
> > > > cloned) and the redefinitions are pervasively applied to all the
> components
> > > in that
> > > > clone. Note that if the schema being redefined has a null target
> namespace,
> > > it may
> > > > be redefined in multiple schemas each with a different namespace and
> each
> > > in a
> > > > different way; in this case, during incorporation, the namespace of the
> > > clone is
> > > > modified to match the namespace of the redefining schema and the other
> > > redefinition
> > > > modifications are applied as well. In any event, the original schema
> remains
> > > > untouched so that it can and will be reused in its pristine form when
> > > referenced
> > > > directly.
> > >
> > > > James Taylor wrote:
> > >
> > > > > Ed,
> > > > >
> > > > > Thank you for the explanation. It's not clear to me how "pervasive"
> the
> > > > > W3C spec
> > > > > ( http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#modify-s chema)
> meant
> > > > > a redefine to be when they state:
> > > > >
> > > > > The modifications have a pervasive impact, that is, only the
> redefined
> > > > > components are used, even when referenced from other incorporated
> > > > > components, whether redefined themselves or not.
> > > > >
> > > > > Given that later in the spec they imply that multiple redefines of the
> > > > > same type that conflict are not legal, I assume they meant that the
> > > > > redefined type should "pervade" everywhere, including in my example of
> > > > > v4.xsd.
> > > > >
> > > > > James
> > > > >
> > > > > Ed Merks wrote:
> > > > >
> > > > > > James,
> > > > >
> > > > > > The v4.xsd schema isn't valid because its includes both a redefined
> > > version
> > > > > of
> > > > > > personName and addressee, via its include of v2.xsd's redefinition of
> > > > > v1.xsd, as
> > > > > > well as the original version of personName and addressee, via its
> > > include of
> > > > > > v3.xsd's include of v1.xsd without redefinition. The v3.xsd schema
> > > needs to
> > > > > > include v2.xsd not v1.xsd for this example to be valid. The bottom
> line
> > > is
> > > > > that
> > > > > > v1.xsd is not modified by virtue of the redefine in v2.xsd; only
> v2.xsd
> > > sees
> > > > > that
> > > > > > redefinition directly and any schema importing or including v2.xsd
> will
> > > see
> > > > > that
> > > > > > redefinition indirectly; but v3.xsd sees only the original v1.xsd and
> > > knows
> > > > > nothing
> > > > > > of v2.xsd. When we get to v4.xsd, the result is name collision.
> > > > >
> > > > > > James Taylor wrote:
> > > > >
> > > > > > > Ed,
> > > > > > >
> > > > > > > Thanks for the reply. My sample is below. In v4.xsd, I would have
> > > > > > > expected that the "marriedPeople" element would contain the
> > > "generation"
> > > > > > > element since it is redefined to include this in v2.xsd. The
> > > > > > > "singlePeople" element does include the "generation" element as
> > > expected.
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > James
> > > > > > >
> > > > > > > v1.xsd:
> > > > > > > <xs:schema
> targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > > elementFormDefault="unqualified"
> attributeFormDefault="unqualified">
> > > > > > > <xs:complexType name="personName">
> > > > > > > <xs:sequence>
> > > > > > > <xs:element name="title" type="xs:string" minOccurs="0"/>
> > > > > > > <xs:element name="forename" type="xs:string" minOccurs="0"
> > > > > > > maxOccurs="unbounded"/>
> > > > > > > </xs:sequence>
> > > > > > > </xs:complexType>
> > > > > > >
> > > > > > > <xs:element name="addressee" type="test:personName"/>
> > > > > > > </xs:schema>
> > > > > > >
> > > > > > > v2.xsd:
> > > > > > > <xs:schema
> targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > > elementFormDefault="unqualified"
> attributeFormDefault="unqualified">
> > > > > > > <xs:redefine schemaLocation="v1.xsd">
> > > > > > > <xs:complexType name="personName">
> > > > > > > <xs:complexContent>
> > > > > > > <xs:extension base="test:personName">
> > > > > > > <xs:sequence>
> > > > > > > <xs:element name="generation" type="xs:string"
> minOccurs="0"/>
> > > > > > > </xs:sequence>
> > > > > > > </xs:extension>
> > > > > > > </xs:complexContent>
> > > > > > > </xs:complexType>
> > > > > > > </xs:redefine>
> > > > > > >
> > > > > > > <xs:element name="author" type="test:personName"/>
> > > > > > > </xs:schema>
> > > > > > >
> > > > > > > v3.xsd:
> > > > > > > <xs:schema
> targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > > elementFormDefault="unqualified"
> attributeFormDefault="unqualified">
> > > > > > > <xs:include schemaLocation="v1.xsd"/>
> > > > > > >
> > > > > > > <xs:complexType name="marriedPersonName">
> > > > > > > <xs:complexContent>
> > > > > > > <xs:extension base="test:personName">
> > > > > > > <xs:sequence>
> > > > > > > <xs:element name="maidenName" type="xs:string"
> minOccurs="0"/>
> > > > > > > </xs:sequence>
> > > > > > > </xs:extension>
> > > > > > > </xs:complexContent>
> > > > > > > </xs:complexType>
> > > > > > >
> > > > > > > <xs:element name="marriedPerson" type="test:marriedPersonName"/>
> > > > > > >
> > > > > > > </xs:schema>
> > > > > > >
> > > > > > > v4.xsd:
> > > > > > > <xs:schema
> targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > > elementFormDefault="unqualified"
> attributeFormDefault="unqualified">
> > > > > > > <xs:include schemaLocation="v2.xsd"/>
> > > > > > > <xs:include schemaLocation="v3.xsd"/>
> > > > > > >
> > > > > > > <xs:complexType name="people">
> > > > > > > <xs:sequence>
> > > > > > > <xs:element name="marriedPeople"
> type="test:marriedPersonName"
> > > > > > > maxOccurs="unbounded"/>
> > > > > > > <xs:element name="singlePeople" type="test:personName"
> > > > > > > maxOccurs="unbounded"/>
> > > > > > > </xs:sequence>
> > > > > > > </xs:complexType>
> > > > > > > <xs:element name="directory" type="test:people"/>
> > > > > > > </xs:schema>
> > > > > > >
> > > > > > > Ed Merks wrote:
> > > > > > >
> > > > > > > > James,
> > > > > > >
> > > > > > > > I'm not sure I can really answer the details of your questions
> > > without
> > > > > clear
> > > > > > > > references to particular components in actual schema documents,
> > > i.e., a
> > > > > > > > sample. Perhaps it helps to explain that redefinition is
> > > accomplished by
> > > > > > > > making a clone of the schema being redefined and then modifying
> that
> > > copy
> > > > > > > > according to the redefinition. The original schema is not
> touched;
> > > it
> > > > > may be
> > > > > > > > redefined many times in many different ways. The schema
> containing
> > > the
> > > > > > > > redefine will see only the copy, not the original. Which version
> you
> > > get
> > > > > will
> > > > > > > > depend very much on where you ask, so you need to be specific...
> > > > > > >
> > > > > > > > James Taylor wrote:
> > > > > > >
> > > > > > > > > Hello,
> > > > > > > > > If I understand the W3C spec correctly, a redefined complexType
> > > should
> > > > > be
> > > > > > > > > used everywhere in place of the original type. For example,
> if I
> > > use
> > > > > the
> > > > > > > > > redefined complexType as a base type for another type, the
> derived
> > > type
> > > > > > > > > should now include the additional elements introduced by the
> > > redefined
> > > > > > > > > type. This is not the behavior I'm seeing in Eclipse XSD.
> When I
> > > get
> > > > > the
> > > > > > > > > base type, using complexTypeDefinition.getBaseType(), I
> continue
> > > to get
> > > > > > > > > the original definition instead of the redefined one.
> References
> > > to
> > > > > the
> > > > > > > > > type within the schema that has the redefine do point to the
> new
> > > > > redefined
> > > > > > > > > type, though. Is this intentional? Should I use a different
> > > > > mechanism to
> > > > > > > > > get the base type? Or is this a bug?
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > >
> > > > > > > > > James

--------------CB5C521ADEF6460EF290FC80
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
James,
<p>I think you need to show the example I showed below to get a clear answer
to the complete question.&nbsp; Multiple different redefines would normally
cause a name conflict, but not for the example below because the redefines
are in different namespaces and hence are redefining different abstract
components.&nbsp; Unless someone says the sample below is invalid <b>and</b>
can point to some constraint in the spec that would justify an error message
for this case, then I will continue to consider the case valid and will
not make changes that would make that case stop working.
<p>The case you show, modified as suggested in the answer to your question
at the schema forum, does work correctly now.&nbsp; Do you have cases without
redundant (and I'm still convinced, invalid) includes that don't work correctly?
<br>&nbsp;
<p>James Taylor wrote:
<blockquote TYPE=CITE>Ed,
<p>Thanks for fixing the bug you found and sorry about the error in
<br>Company.xsd.&nbsp; I sent a question to the W3C regarding redefines
because I
<br>don't think the spec is as clear as it could be, and the answers I
<br>received clarify things:
<p><a href=" http://lists.w3.org/Archives/Public/xmlschema-dev/2004Mar/00 54.html"> http://lists.w3.org/Archives/Public/xmlschema-dev/2004Mar/00 54.html</a>
<p>I understand the revised example you've shown below is an alternative,
<br>however, it still should work the way I expressed it.&nbsp; The reason
this is
<br>an important issue for us here at my company is that our schemas can
<br>become large with many levels of nesting.&nbsp; Being forced to redefine
every
<br>encompassing type for all occurrences of a type becomes cumbersome
and
<br>potentially error prone if an occurrence is missed.&nbsp; It can also
prevents
<br>being able to redefine a type nested inside of element declaration
with an
<br>anonymous type.
<p>I'll volunteer to fix it if that helps.
<p>&nbsp;&nbsp;&nbsp; James
<p>Ed Merks wrote:
<br>> James,
<p>> As I was fixing the Company.xsd to make it valid:
<p>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:schema targetNamespace="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; xmlns:test="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; xmlns:xs="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; elementFormDefault="unqualified" attributeFormDefault="unqualified">
<p>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;xs:redefine schemaLocation="Department.xsd">
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &lt;xs:complexType
name="Employee">
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xs:complexContent>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;
&lt;xs:extension base="test:Employee">
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
&lt;xs:sequence>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xs:element name="ranking" type="xs:int"/>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
&lt;/xs:sequence>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;
&lt;/xs:extension>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;/xs:complexContent>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &lt;/xs:complexType>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;/xs:redefine>
<p>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;xs:complexType name="Company">
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &lt;xs:sequence>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xs:element name="department" type="test:Department"
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; maxOccurs="unbounded"/>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xs:element name="president" type="test:Employee"/>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &lt;/xs:sequence>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;/xs:complexType>
<p>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;xs:element name="fortune500"
type="test:Company"/>
<p>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:schema>
<p>> I discovered that there is a bug that causes the transitive
<br>includes/redefines of a
<br>> cloned included/redefined schema to be omitted so I opened
<br>> <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=56328">https://bugs.eclipse.org/bugs/show_bug.cgi?id=56328</a>
and have fixed that
<br>particular
<br>> problem. So, to my way of thinking, the above sample is the correct
way to
<br>express
<br>> what you intended.
<p>> Consider the following slightly modified example where Employee.xsd
has no
<br>> namespace:
<p>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:schema
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; xmlns:xs="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; elementFormDefault="unqualified" attributeFormDefault="unqualified">
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;xs:complexType name="Employee">
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &lt;xs:sequence>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xs:element name="name" type="xs:string"/>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &lt;/xs:sequence>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;/xs:complexType>
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:schema>
<p>> and Department.xsd is still the same (but the include is changing
the null
<br>> namespace of the included schema to match that of the including schema):
<p>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:schema targetNamespace="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; xmlns:test="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; xmlns:xs="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; elementFormDefault="unqualified" attributeFormDefault="unqualified">
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;xs:include schemaLocation="Employee.xsd"/>
<p>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;xs:complexType name="Department">
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &lt;xs:sequence>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xs:element name="employee" type="test:Employee"
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; maxOccurs="unbounded"/>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xs:element name="manager" type="test:Employee"/>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &lt;/xs:sequence>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;/xs:complexType>
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:schema>
<p>> In this case, a Company.xsd can validly access both the original version
of
<br>> Employee as well as a redefined version.
<p>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:schema targetNamespace="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; xmlns:test="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; xmlns:xs="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; elementFormDefault="unqualified" attributeFormDefault="unqualified">
<p>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;xs:import schemaLocation="Employee.xsd"/>
<p>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;xs:redefine schemaLocation="Department.xsd">
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &lt;xs:complexType
name="Employee">
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xs:complexContent>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;
&lt;xs:extension base="test:Employee">
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
&lt;xs:sequence>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xs:element name="ranking" type="xs:int"/>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
&lt;/xs:sequence>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;
&lt;/xs:extension>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;/xs:complexContent>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &lt;/xs:complexType>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;/xs:redefine>
<p>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;xs:complexType name="Company">
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &lt;xs:sequence>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xs:element name="department" type="test:Department"
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; maxOccurs="unbounded"/>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xs:element name="president" type="test:Employee"/>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xs:element name="dummy" type="Employee"/>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &lt;/xs:sequence>
<br>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;/xs:complexType>
<p>> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;xs:element name="fortune500"
type="test:Company"/>
<p>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:schema>
<p>> The semantics view for this shows that everyone is using the redefined
type,
<br>except
<br>> the junk element, which is using the original:
<p>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [Image]
<p>> This stuff is all really much too complicated for human minds to handle
(and
<br>I
<br>> think there are still lurking bugs in the implementation, but I don't
have
<br>any more
<br>> time to spend to look at this further).
<p>> James Taylor wrote:
<p>> > Ed,
<br>> >
<br>> > Here's a smaller more realistic example that illustrates an issue:
<br>> >
<br>> > File A defines Employee type
<br>> > File B includes File A and defines Department type
<br>> > File C includes File B, redefines Employee from File A and defines
Company
<br>> > type
<br>> >
<br>> > This is a common use case for redefine in which a type in a nested
include
<br>> > needs to be redefined.&nbsp; With Eclipse XSD, the redefine does
not affect the
<br>> > Employee type within the Department type and affects the Employee
type
<br>> > within the Company type only if the include of File B precedes
the
<br>> > redefine of File A.&nbsp; This does not seem like the correct behavior.
<br>> >
<br>> > I've included the XSD files below.&nbsp; Thanks,
<br>> >
<br>> >&nbsp;&nbsp;&nbsp;&nbsp; James
<br>> >
<br>> > Employee.xsd:
<br>> > &lt;xs:schema targetNamespace="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>> > xmlns:test="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>> > xmlns:xs="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>> > elementFormDefault="unqualified" attributeFormDefault="unqualified">
<br>> >&nbsp;&nbsp; &lt;xs:complexType name="Employee">
<br>> >&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:sequence>
<br>> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="name"
type="xs:string"/>
<br>> >&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:sequence>
<br>> >&nbsp;&nbsp; &lt;/xs:complexType>
<br>> > &lt;/xs:schema>
<br>> >
<br>> > Department.xsd:
<br>> > &lt;xs:schema targetNamespace="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>> > xmlns:test="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>> > xmlns:xs="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>> > elementFormDefault="unqualified" attributeFormDefault="unqualified">
<br>> >&nbsp;&nbsp; &lt;xs:include schemaLocation="Employee.xsd"/>
<br>> >
<br>> >&nbsp;&nbsp; &lt;xs:complexType name="Department">
<br>> >&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:sequence>
<br>> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="employee"
type="test:Employee"
<br>> > maxOccurs="unbounded"/>
<br>> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="manager"
type="test:Employee"/>
<br>> >&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:sequence>
<br>> >&nbsp;&nbsp; &lt;/xs:complexType>
<br>> > &lt;/xs:schema>
<br>> >
<br>> > Company.xsd:
<br>> > &lt;xs:schema targetNamespace="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>> > xmlns:test="<a href="http://namespaces.nextance.com/test">http://namespaces.nextance.com/test</a>"
<br>> > xmlns:xs="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>> > elementFormDefault="unqualified" attributeFormDefault="unqualified">
<br>> >
<br>> >&nbsp;&nbsp; &lt;xs:include schemaLocation="Department.xsd"/>
<br>> >
<br>> >&nbsp;&nbsp; &lt;xs:redefine schemaLocation="Employee.xsd">
<br>> >&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:complexType name="Employee">
<br>> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:complexContent>
<br>> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; &lt;xs:extension
base="test:Employee">
<br>> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:sequence>
<br>> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xs:element name="ranking" type="xs:int"/>
<br>> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:sequence>
<br>> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; &lt;/xs:extension>
<br>> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:complexContent>
<br>> >&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:complexType>
<br>> >&nbsp;&nbsp; &lt;/xs:redefine>
<br>> >
<br>> >&nbsp;&nbsp; &lt;xs:complexType name="Company">
<br>> >&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:sequence>
<br>> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="department"
type="test:Department"
<br>> > maxOccurs="unbounded"/>
<br>> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;xs:element name="president"
type="test:Employee"/>
<br>> >&nbsp;&nbsp;&nbsp;&nbsp; &lt;/xs:sequence>
<br>> >&nbsp;&nbsp; &lt;/xs:complexType>
<br>> >
<br>> >&nbsp;&nbsp; &lt;xs:element name="fortune500" type="test:Company"
maxOccurs="500"/>
<br>> >
<br>> > &lt;/xs:schema>
<br>> >
<br>> > Ed Merks wrote:
<br>> >
<br>> > > James,
<br>> >
<br>> > > All the components of the schema mentioned in the redefine are
<br>incorporated
<br>> > (i.e.,
<br>> > > cloned) and the redefinitions are pervasively applied to all
the
<br>components
<br>> > in that
<br>> > > clone.&nbsp; Note that if the schema being redefined has a null
target
<br>namespace,
<br>> > it may
<br>> > > be redefined in&nbsp; multiple schemas each with a different
namespace and
<br>each
<br>> > in a
<br>> > > different way; in this case, during incorporation, the namespace
of the
<br>> > clone is
<br>> > > modified to match the namespace of the redefining schema and
the other
<br>> > redefinition
<br>> > > modifications are applied as well.&nbsp; In any event, the original
schema
<br>remains
<br>> > > untouched so that it can and will be reused in its pristine form
when
<br>> > referenced
<br>> > > directly.
<br>> >
<br>> > > James Taylor wrote:
<br>> >
<br>> > > > Ed,
<br>> > > >
<br>> > > > Thank you for the explanation.&nbsp; It's not clear to me how
"pervasive"
<br>the
<br>> > > > W3C spec
<br>> > > > (<a href=" http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#modify-s chema"> http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#modify-s chema</a>)
<br>meant
<br>> > > > a redefine to be when they state:
<br>> > > >
<br>> > > >&nbsp;&nbsp;&nbsp;&nbsp; The modifications have a pervasive
impact, that is, only the
<br>redefined
<br>> > > >&nbsp;&nbsp;&nbsp;&nbsp; components are used, even when referenced
from other incorporated
<br>> > > >&nbsp;&nbsp;&nbsp;&nbsp; components, whether redefined themselves
or not.
<br>> > > >
<br>> > > > Given that later in the spec they imply that multiple redefines
of the
<br>> > > > same type that conflict are not legal, I assume they meant
that the
<br>> > > > redefined type should "pervade" everywhere, including in my
example of
<br>> > > > v4.xsd.
<br>> > > >
<br>> > > >&nbsp;&nbsp;&nbsp;&nbsp; James
<br>> > > >
<br>> > > > Ed Merks wrote:
<br>> > > >
<br>> > > > > James,
<br>> > > >
<br>> > > > > The v4.xsd schema isn't valid because its includes both a
redefined
<br>> > version
<br>> > > > of
<br>> > > > > personName and addressee, via its include of v2.xsd's redefinition
of
<br>> > > > v1.xsd, as
<br>> > > > > well as the original version of personName and addressee,
via its
<br>> > include of
<br>> > > > > v3.xsd's include of v1.xsd without redefinition.&nbsp; The
v3.xsd schema
<br>> > needs to
<br>> > > > > include v2.xsd not v1.xsd for this example to be valid.&nbsp;
The bottom
<br>line
<br>> > is
<br>> > > > that
<br>> > > > > v1.xsd is not modified by virtue of the redefine in v2.xsd;
only
<br>v2.xsd
<br>> > sees
<br>> > > > that
<br>> > > > > redefinition directly and any schema importing or including
v2.xsd
<br>will
<br>> > see
<br>> > > > that
<br>> > > > > redefinition indirectly; but v3.xsd sees only the original
v1.xsd and
<br>> > knows
<br>> > > > nothing
<br>> > > > > of v2.xsd.&nbsp; When we get to v4.xsd, the result is name
collision.
<br>> > > >
<br>> > > > > James Taylor wrote:
<br>> > > >
<br>> > > > > > Ed,
<br>> > > > > >
<br>> > > > > > Thanks for the reply.&nbsp; My sample is below.&nbsp; In
v4.xsd, I would have
<br>> > > > > > expected that the "marriedPeople" element would contain
the
<br>> > "generation"
<br>> > > > > > element since it is redefined to include this in v2.xsd.&nbsp;
The
<br>> > > > > > "singlePeople" element does include the "generation" element
as
<br>> > expected.
<br>> > > > > >
<br>> > > > > > Thanks,
<br>> > > > > >
<br>> > > > > >&nbsp;&nbsp;&nbsp;&nbsp; James
<br>> > > > > >
<br>> > > > > > v1.xsd:
<br>> > > > > > &lt;xs:schema
<br>targetNamespace="<a href="http://namespaces.nextance.com/nex/test">http://namespaces.nextance.com/nex/test</a>"
<br>> > >

Ed Merks
Professional Support: https://www.macromodeling.com/
Re: redefine [message #584972 is a reply to message #40108] Wed, 31 March 2004 00:16
 James TaylorMessages: 21Registered: July 2009 Junior Member
Ed,

I got the latest XSD from CVS and everything works fine. Thanks again for
the bug fix -- I didn't realize it fixed my test case. I agree with you
that your example should work as well, since there are really two Employee
types one with no namespace and the other with a namespace. I tried it
with the W3C schema validator (XSV) against a test instance and it worked
fine.

James

Ed Merks wrote:

> James,

> I think you need to show the example I showed below to get a clear answer to
the
> complete question. Multiple different redefines would normally cause a name
> conflict, but not for the example below because the redefines are in
different
> namespaces and hence are redefining different abstract components. Unless
someone
> says the sample below is invalid and can point to some constraint in the
spec that
> would justify an error message for this case, then I will continue to
consider the
> case valid and will not make changes that would make that case stop working.

> The case you show, modified as suggested in the answer to your question at
the
> schema forum, does work correctly now. Do you have cases without redundant
(and
> I'm still convinced, invalid) includes that don't work correctly?

> James Taylor wrote:

> > Ed,
> >
> > Thanks for fixing the bug you found and sorry about the error in
> > Company.xsd. I sent a question to the W3C regarding redefines because I
> > don't think the spec is as clear as it could be, and the answers I
> > received clarify things:
> >
> > http://lists.w3.org/Archives/Public/xmlschema-dev/2004Mar/00 54.html
> >
> > I understand the revised example you've shown below is an alternative,
> > however, it still should work the way I expressed it. The reason this is
> > an important issue for us here at my company is that our schemas can
> > become large with many levels of nesting. Being forced to redefine every
> > encompassing type for all occurrences of a type becomes cumbersome and
> > potentially error prone if an occurrence is missed. It can also prevents
> > being able to redefine a type nested inside of element declaration with an
> > anonymous type.
> >
> > I'll volunteer to fix it if that helps.
> >
> > James
> >
> > Ed Merks wrote:
> > > James,
> >
> > > As I was fixing the Company.xsd to make it valid:
> >
> > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > xmlns:test="http://namespaces.nextance.com/test"
> > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> >
> > > <xs:redefine schemaLocation="Department.xsd">
> > > <xs:complexType name="Employee">
> > > <xs:complexContent>
> > > <xs:extension base="test:Employee">
> > > <xs:sequence>
> > > <xs:element name="ranking" type="xs:int"/>
> > > </xs:sequence>
> > > </xs:extension>
> > > </xs:complexContent>
> > > </xs:complexType>
> > > </xs:redefine>
> >
> > > <xs:complexType name="Company">
> > > <xs:sequence>
> > > <xs:element name="department" type="test:Department"
> > > maxOccurs="unbounded"/>
> > > <xs:element name="president" type="test:Employee"/>
> > > </xs:sequence>
> > > </xs:complexType>
> >
> > > <xs:element name="fortune500" type="test:Company"/>
> >
> > > </xs:schema>
> >
> > > I discovered that there is a bug that causes the transitive
> > includes/redefines of a
> > > cloned included/redefined schema to be omitted so I opened
> > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=56328 and have fixed that
> > particular
> > > problem. So, to my way of thinking, the above sample is the correct way
to
> > express
> > > what you intended.
> >
> > > Consider the following slightly modified example where Employee.xsd has
no
> > > namespace:
> >
> > > <xs:schema
> > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > <xs:complexType name="Employee">
> > > <xs:sequence>
> > > <xs:element name="name" type="xs:string"/>
> > > </xs:sequence>
> > > </xs:complexType>
> > > </xs:schema>
> >
> > > and Department.xsd is still the same (but the include is changing the
null
> > > namespace of the included schema to match that of the including schema):
> >
> > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > xmlns:test="http://namespaces.nextance.com/test"
> > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > <xs:include schemaLocation="Employee.xsd"/>
> >
> > > <xs:complexType name="Department">
> > > <xs:sequence>
> > > <xs:element name="employee" type="test:Employee"
> > > maxOccurs="unbounded"/>
> > > <xs:element name="manager" type="test:Employee"/>
> > > </xs:sequence>
> > > </xs:complexType>
> > > </xs:schema>
> >
> > > In this case, a Company.xsd can validly access both the original version
of
> > > Employee as well as a redefined version.
> >
> > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > xmlns:test="http://namespaces.nextance.com/test"
> > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> >
> > > <xs:import schemaLocation="Employee.xsd"/>
> >
> > > <xs:redefine schemaLocation="Department.xsd">
> > > <xs:complexType name="Employee">
> > > <xs:complexContent>
> > > <xs:extension base="test:Employee">
> > > <xs:sequence>
> > > <xs:element name="ranking" type="xs:int"/>
> > > </xs:sequence>
> > > </xs:extension>
> > > </xs:complexContent>
> > > </xs:complexType>
> > > </xs:redefine>
> >
> > > <xs:complexType name="Company">
> > > <xs:sequence>
> > > <xs:element name="department" type="test:Department"
> > > maxOccurs="unbounded"/>
> > > <xs:element name="president" type="test:Employee"/>
> > > <xs:element name="dummy" type="Employee"/>
> > > </xs:sequence>
> > > </xs:complexType>
> >
> > > <xs:element name="fortune500" type="test:Company"/>
> >
> > > </xs:schema>
> >
> > > The semantics view for this shows that everyone is using the redefined
type,
> > except
> > > the junk element, which is using the original:
> >
> > > [Image]
> >
> > > This stuff is all really much too complicated for human minds to handle
(and
> > I
> > > think there are still lurking bugs in the implementation, but I don't
have
> > any more
> > > time to spend to look at this further).
> >
> > > James Taylor wrote:
> >
> > > > Ed,
> > > >
> > > > Here's a smaller more realistic example that illustrates an issue:
> > > >
> > > > File A defines Employee type
> > > > File B includes File A and defines Department type
> > > > File C includes File B, redefines Employee from File A and defines
Company
> > > > type
> > > >
> > > > This is a common use case for redefine in which a type in a nested
include
> > > > needs to be redefined. With Eclipse XSD, the redefine does not affect
the
> > > > Employee type within the Department type and affects the Employee type
> > > > within the Company type only if the include of File B precedes the
> > > > redefine of File A. This does not seem like the correct behavior.
> > > >
> > > > I've included the XSD files below. Thanks,
> > > >
> > > > James
> > > >
> > > > Employee.xsd:
> > > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > > xmlns:test="http://namespaces.nextance.com/test"
> > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > <xs:complexType name="Employee">
> > > > <xs:sequence>
> > > > <xs:element name="name" type="xs:string"/>
> > > > </xs:sequence>
> > > > </xs:complexType>
> > > > </xs:schema>
> > > >
> > > > Department.xsd:
> > > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > > xmlns:test="http://namespaces.nextance.com/test"
> > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > <xs:include schemaLocation="Employee.xsd"/>
> > > >
> > > > <xs:complexType name="Department">
> > > > <xs:sequence>
> > > > <xs:element name="employee" type="test:Employee"
> > > > maxOccurs="unbounded"/>
> > > > <xs:element name="manager" type="test:Employee"/>
> > > > </xs:sequence>
> > > > </xs:complexType>
> > > > </xs:schema>
> > > >
> > > > Company.xsd:
> > > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > > xmlns:test="http://namespaces.nextance.com/test"
> > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > >
> > > > <xs:include schemaLocation="Department.xsd"/>
> > > >
> > > > <xs:redefine schemaLocation="Employee.xsd">
> > > > <xs:complexType name="Employee">
> > > > <xs:complexContent>
> > > > <xs:extension base="test:Employee">
> > > > <xs:sequence>
> > > > <xs:element name="ranking" type="xs:int"/>
> > > > </xs:sequence>
> > > > </xs:extension>
> > > > </xs:complexContent>
> > > > </xs:complexType>
> > > > </xs:redefine>
> > > >
> > > > <xs:complexType name="Company">
> > > > <xs:sequence>
> > > > <xs:element name="department" type="test:Department"
> > > > maxOccurs="unbounded"/>
> > > > <xs:element name="president" type="test:Employee"/>
> > > > </xs:sequence>
> > > > </xs:complexType>
> > > >
> > > > <xs:element name="fortune500" type="test:Company" maxOccurs="500"/>
> > > >
> > > > </xs:schema>
> > > >
> > > > Ed Merks wrote:
> > > >
> > > > > James,
> > > >
> > > > > All the components of the schema mentioned in the redefine are
> > incorporated
> > > > (i.e.,
> > > > > cloned) and the redefinitions are pervasively applied to all the
> > components
> > > > in that
> > > > > clone. Note that if the schema being redefined has a null target
> > namespace,
> > > > it may
> > > > > be redefined in multiple schemas each with a different namespace and
> > each
> > > > in a
> > > > > different way; in this case, during incorporation, the namespace of
the
> > > > clone is
> > > > > modified to match the namespace of the redefining schema and the
other
> > > > redefinition
> > > > > modifications are applied as well. In any event, the original schema
> > remains
> > > > > untouched so that it can and will be reused in its pristine form when
> > > > referenced
> > > > > directly.
> > > >
> > > > > James Taylor wrote:
> > > >
> > > > > > Ed,
> > > > > >
> > > > > > Thank you for the explanation. It's not clear to me how
"pervasive"
> > the
> > > > > > W3C spec
> > > > > > ( http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#modify-s chema)
> > meant
> > > > > > a redefine to be when they state:
> > > > > >
> > > > > > The modifications have a pervasive impact, that is, only the
> > redefined
> > > > > > components are used, even when referenced from other
incorporated
> > > > > > components, whether redefined themselves or not.
> > > > > >
> > > > > > Given that later in the spec they imply that multiple redefines of
the
> > > > > > same type that conflict are not legal, I assume they meant that the
> > > > > > redefined type should "pervade" everywhere, including in my
example of
> > > > > > v4.xsd.
> > > > > >
> > > > > > James
> > > > > >
> > > > > > Ed Merks wrote:
> > > > > >
> > > > > > > James,
> > > > > >
> > > > > > > The v4.xsd schema isn't valid because its includes both a
redefined
> > > > version
> > > > > > of
> > > > > > > personName and addressee, via its include of v2.xsd's
redefinition of
> > > > > > v1.xsd, as
> > > > > > > well as the original version of personName and addressee, via its
> > > > include of
> > > > > > > v3.xsd's include of v1.xsd without redefinition. The v3.xsd
schema
> > > > needs to
> > > > > > > include v2.xsd not v1.xsd for this example to be valid. The
bottom
> > line
> > > > is
> > > > > > that
> > > > > > > v1.xsd is not modified by virtue of the redefine in v2.xsd; only
> > v2.xsd
> > > > sees
> > > > > > that
> > > > > > > redefinition directly and any schema importing or including
v2.xsd
> > will
> > > > see
> > > > > > that
> > > > > > > redefinition indirectly; but v3.xsd sees only the original
v1.xsd and
> > > > knows
> > > > > > nothing
> > > > > > > of v2.xsd. When we get to v4.xsd, the result is name collision.
> > > > > >
> > > > > > > James Taylor wrote:
> > > > > >
> > > > > > > > Ed,
> > > > > > > >
> > > > > > > > Thanks for the reply. My sample is below. In v4.xsd, I would
have
> > > > > > > > expected that the "marriedPeople" element would contain the
> > > > "generation"
> > > > > > > > element since it is redefined to include this in v2.xsd. The
> > > > > > > > "singlePeople" element does include the "generation" element as
> > > > expected.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > >
> > > > > > > > James
> > > > > > > >
> > > > > > > > v1.xsd:
> > > > > > > > <xs:schema
> > targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > > > elementFormDefault="unqualified"
> > attributeFormDefault="unqualified">
> > > > > > > > <xs:complexType name="personName">
> > > > > > > > <xs:sequence>
> > > > > > > > <xs:element name="title" type="xs:string" minOccurs="0"/>
> > > > > > > > <xs:element name="forename" type="xs:string" minOccurs="0"
> > > > > > > > maxOccurs="unbounded"/>
> > > > > > > > </xs:sequence>
> > > > > > > > </xs:complexType>
> > > > > > > >
> > > > > > > > <xs:element name="addressee" type="test:personName"/>
> > > > > > > > </xs:schema>
> > > > > > > >
> > > > > > > > v2.xsd:
> > > > > > > > <xs:schema
> > targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > > > elementFormDefault="unqualified"
> > attributeFormDefault="unqualified">
> > > > > > > > <xs:redefine schemaLocation="v1.xsd">
> > > > > > > > <xs:complexType name="personName">
> > > > > > > > <xs:complexContent>
> > > > > > > > <xs:extension base="test:personName">
> > > > > > > > <xs:sequence>
> > > > > > > > <xs:element name="generation" type="xs:string"
> > minOccurs="0"/>
> > > > > > > > </xs:sequence>
> > > > > > > > </xs:extension>
> > > > > > > > </xs:complexContent>
> > > > > > > > </xs:complexType>
> > > > > > > > </xs:redefine>
> > > > > > > >
> > > > > > > > <xs:element name="author" type="test:personName"/>
> > > > > > > > </xs:schema>
> > > > > > > >
> > > > > > > > v3.xsd:
> > > > > > > > <xs:schema
> > targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > > > elementFormDefault="unqualified"
> > attributeFormDefault="unqualified">
> > > > > > > > <xs:include schemaLocation="v1.xsd"/>
> > > > > > > >
> > > > > > > > <xs:complexType name="marriedPersonName">
> > > > > > > > <xs:complexContent>
> > > > > > > > <xs:extension base="test:personName">
> > > > > > > > <xs:sequence>
> > > > > > > > <xs:element name="maidenName" type="xs:string"
> > minOccurs="0"/>
> > > > > > > > </xs:sequence>
> > > > > > > > </xs:extension>
> > > > > > > > </xs:complexContent>
> > > > > > > > </xs:complexType>
> > > > > > > >
> > > > > > > > <xs:element name="marriedPerson"
type="test:marriedPersonName"/>
> > > > > > > >
> > > > > > > > </xs:schema>
> > > > > > > >
> > > > > > > > v4.xsd:
> > > > > > > > <xs:schema
> > targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > > > elementFormDefault="unqualified"
> > attributeFormDefault="unqualified">
> > > > > > > > <xs:include schemaLocation="v2.xsd"/>
> > > > > > > > <xs:include schemaLocation="v3.xsd"/>
> > > > > > > >
> > > > > > > > <xs:complexType name="people">
> > > > > > > > <xs:sequence>
> > > > > > > > <xs:element name="marriedPeople"
> > type="test:marriedPersonName"
> > > > > > > > maxOccurs="unbounded"/>
> > > > > > > > <xs:element name="singlePeople" type="test:personName"
> > > > > > > > maxOccurs="unbounded"/>
> > > > > > > > </xs:sequence>
> > > > > > > > </xs:complexType>
> > > > > > > > <xs:element name="directory" type="test:people"/>
> > > > > > > > </xs:schema>
> > > > > > > >
> > > > > > > > Ed Merks wrote:
> > > > > > > >
> > > > > > > > > James,
> > > > > > > >
> > > > > > > > > I'm not sure I can really answer the details of your
questions
> > > > without
> > > > > > clear
> > > > > > > > > references to particular components in actual schema
documents,
> > > > i.e., a
> > > > > > > > > sample. Perhaps it helps to explain that redefinition is
> > > > accomplished by
> > > > > > > > > making a clone of the schema being redefined and then
modifying
> > that
> > > > copy
> > > > > > > > > according to the redefinition. The original schema is not
> > touched;
> > > > it
> > > > > > may be
> > > > > > > > > redefined many times in many different ways. The schema
> > containing
> > > > the
> > > > > > > > > redefine will see only the copy, not the original. Which
version
> > you
> > > > get
> > > > > > will
> > > > > > > > > depend very much on where you ask, so you need to be
specific...
> > > > > > > >
> > > > > > > > > James Taylor wrote:
> > > > > > > >
> > > > > > > > > > Hello,
> > > > > > > > > > If I understand the W3C spec correctly, a redefined
complexType
> > > > should
> > > > > > be
> > > > > > > > > > used everywhere in place of the original type. For
example,
> > if I
> > > > use
> > > > > > the
> > > > > > > > > > redefined complexType as a base type for another type, the
> > derived
> > > > type
> > > > > > > > > > should now include the additional elements introduced by
the
> > > > redefined
> > > > > > > > > > type. This is not the behavior I'm seeing in Eclipse XSD.
> > When I
> > > > get
> > > > > > the
> > > > > > > > > > base type, using complexTypeDefinition.getBaseType(), I
> > continue
> > > > to get
> > > > > > > > > > the original definition instead of the redefined one.
> > References
> > > > to
> > > > > > the
> > > > > > > > > > type within the schema that has the redefine do point to
the
> > new
> > > > > > redefined
> > > > > > > > > > type, though. Is this intentional? Should I use a
different
> > > > > > mechanism to
> > > > > > > > > > get the base type? Or is this a bug?
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > >
> > > > > > > > > > James
Re: redefine [message #585234 is a reply to message #40108] Fri, 09 April 2004 03:00
 James TaylorMessages: 21Registered: July 2009 Junior Member
Ed,

I believe I found a redefine bug. Complex types that are derived from
types that are redefined continue to pick up the old type definition when
these types are included. For example, in the case I showed below, if
there was a Manager complexType with an Employee base type, the Manager
type when used in the Company.xsd does not pick up the new "rank" element
from the redefinition.

Let me know if you'd rather I just file a bug that post this here. Thanks,

James

Ed Merks wrote:

> James,

> I think you need to show the example I showed below to get a clear answer to
the
> complete question. Multiple different redefines would normally cause a name
> conflict, but not for the example below because the redefines are in
different
> namespaces and hence are redefining different abstract components. Unless
someone
> says the sample below is invalid and can point to some constraint in the
spec that
> would justify an error message for this case, then I will continue to
consider the
> case valid and will not make changes that would make that case stop working.

> The case you show, modified as suggested in the answer to your question at
the
> schema forum, does work correctly now. Do you have cases without redundant
(and
> I'm still convinced, invalid) includes that don't work correctly?

> James Taylor wrote:

> > Ed,
> >
> > Thanks for fixing the bug you found and sorry about the error in
> > Company.xsd. I sent a question to the W3C regarding redefines because I
> > don't think the spec is as clear as it could be, and the answers I
> > received clarify things:
> >
> > http://lists.w3.org/Archives/Public/xmlschema-dev/2004Mar/00 54.html
> >
> > I understand the revised example you've shown below is an alternative,
> > however, it still should work the way I expressed it. The reason this is
> > an important issue for us here at my company is that our schemas can
> > become large with many levels of nesting. Being forced to redefine every
> > encompassing type for all occurrences of a type becomes cumbersome and
> > potentially error prone if an occurrence is missed. It can also prevents
> > being able to redefine a type nested inside of element declaration with an
> > anonymous type.
> >
> > I'll volunteer to fix it if that helps.
> >
> > James
> >
> > Ed Merks wrote:
> > > James,
> >
> > > As I was fixing the Company.xsd to make it valid:
> >
> > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > xmlns:test="http://namespaces.nextance.com/test"
> > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> >
> > > <xs:redefine schemaLocation="Department.xsd">
> > > <xs:complexType name="Employee">
> > > <xs:complexContent>
> > > <xs:extension base="test:Employee">
> > > <xs:sequence>
> > > <xs:element name="ranking" type="xs:int"/>
> > > </xs:sequence>
> > > </xs:extension>
> > > </xs:complexContent>
> > > </xs:complexType>
> > > </xs:redefine>
> >
> > > <xs:complexType name="Company">
> > > <xs:sequence>
> > > <xs:element name="department" type="test:Department"
> > > maxOccurs="unbounded"/>
> > > <xs:element name="president" type="test:Employee"/>
> > > </xs:sequence>
> > > </xs:complexType>
> >
> > > <xs:element name="fortune500" type="test:Company"/>
> >
> > > </xs:schema>
> >
> > > I discovered that there is a bug that causes the transitive
> > includes/redefines of a
> > > cloned included/redefined schema to be omitted so I opened
> > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=56328 and have fixed that
> > particular
> > > problem. So, to my way of thinking, the above sample is the correct way
to
> > express
> > > what you intended.
> >
> > > Consider the following slightly modified example where Employee.xsd has
no
> > > namespace:
> >
> > > <xs:schema
> > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > <xs:complexType name="Employee">
> > > <xs:sequence>
> > > <xs:element name="name" type="xs:string"/>
> > > </xs:sequence>
> > > </xs:complexType>
> > > </xs:schema>
> >
> > > and Department.xsd is still the same (but the include is changing the
null
> > > namespace of the included schema to match that of the including schema):
> >
> > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > xmlns:test="http://namespaces.nextance.com/test"
> > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > <xs:include schemaLocation="Employee.xsd"/>
> >
> > > <xs:complexType name="Department">
> > > <xs:sequence>
> > > <xs:element name="employee" type="test:Employee"
> > > maxOccurs="unbounded"/>
> > > <xs:element name="manager" type="test:Employee"/>
> > > </xs:sequence>
> > > </xs:complexType>
> > > </xs:schema>
> >
> > > In this case, a Company.xsd can validly access both the original version
of
> > > Employee as well as a redefined version.
> >
> > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > xmlns:test="http://namespaces.nextance.com/test"
> > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> >
> > > <xs:import schemaLocation="Employee.xsd"/>
> >
> > > <xs:redefine schemaLocation="Department.xsd">
> > > <xs:complexType name="Employee">
> > > <xs:complexContent>
> > > <xs:extension base="test:Employee">
> > > <xs:sequence>
> > > <xs:element name="ranking" type="xs:int"/>
> > > </xs:sequence>
> > > </xs:extension>
> > > </xs:complexContent>
> > > </xs:complexType>
> > > </xs:redefine>
> >
> > > <xs:complexType name="Company">
> > > <xs:sequence>
> > > <xs:element name="department" type="test:Department"
> > > maxOccurs="unbounded"/>
> > > <xs:element name="president" type="test:Employee"/>
> > > <xs:element name="dummy" type="Employee"/>
> > > </xs:sequence>
> > > </xs:complexType>
> >
> > > <xs:element name="fortune500" type="test:Company"/>
> >
> > > </xs:schema>
> >
> > > The semantics view for this shows that everyone is using the redefined
type,
> > except
> > > the junk element, which is using the original:
> >
> > > [Image]
> >
> > > This stuff is all really much too complicated for human minds to handle
(and
> > I
> > > think there are still lurking bugs in the implementation, but I don't
have
> > any more
> > > time to spend to look at this further).
> >
> > > James Taylor wrote:
> >
> > > > Ed,
> > > >
> > > > Here's a smaller more realistic example that illustrates an issue:
> > > >
> > > > File A defines Employee type
> > > > File B includes File A and defines Department type
> > > > File C includes File B, redefines Employee from File A and defines
Company
> > > > type
> > > >
> > > > This is a common use case for redefine in which a type in a nested
include
> > > > needs to be redefined. With Eclipse XSD, the redefine does not affect
the
> > > > Employee type within the Department type and affects the Employee type
> > > > within the Company type only if the include of File B precedes the
> > > > redefine of File A. This does not seem like the correct behavior.
> > > >
> > > > I've included the XSD files below. Thanks,
> > > >
> > > > James
> > > >
> > > > Employee.xsd:
> > > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > > xmlns:test="http://namespaces.nextance.com/test"
> > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > <xs:complexType name="Employee">
> > > > <xs:sequence>
> > > > <xs:element name="name" type="xs:string"/>
> > > > </xs:sequence>
> > > > </xs:complexType>
> > > > </xs:schema>
> > > >
> > > > Department.xsd:
> > > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > > xmlns:test="http://namespaces.nextance.com/test"
> > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > <xs:include schemaLocation="Employee.xsd"/>
> > > >
> > > > <xs:complexType name="Department">
> > > > <xs:sequence>
> > > > <xs:element name="employee" type="test:Employee"
> > > > maxOccurs="unbounded"/>
> > > > <xs:element name="manager" type="test:Employee"/>
> > > > </xs:sequence>
> > > > </xs:complexType>
> > > > </xs:schema>
> > > >
> > > > Company.xsd:
> > > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > > xmlns:test="http://namespaces.nextance.com/test"
> > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > >
> > > > <xs:include schemaLocation="Department.xsd"/>
> > > >
> > > > <xs:redefine schemaLocation="Employee.xsd">
> > > > <xs:complexType name="Employee">
> > > > <xs:complexContent>
> > > > <xs:extension base="test:Employee">
> > > > <xs:sequence>
> > > > <xs:element name="ranking" type="xs:int"/>
> > > > </xs:sequence>
> > > > </xs:extension>
> > > > </xs:complexContent>
> > > > </xs:complexType>
> > > > </xs:redefine>
> > > >
> > > > <xs:complexType name="Company">
> > > > <xs:sequence>
> > > > <xs:element name="department" type="test:Department"
> > > > maxOccurs="unbounded"/>
> > > > <xs:element name="president" type="test:Employee"/>
> > > > </xs:sequence>
> > > > </xs:complexType>
> > > >
> > > > <xs:element name="fortune500" type="test:Company" maxOccurs="500"/>
> > > >
> > > > </xs:schema>
> > > >
> > > > Ed Merks wrote:
> > > >
> > > > > James,
> > > >
> > > > > All the components of the schema mentioned in the redefine are
> > incorporated
> > > > (i.e.,
> > > > > cloned) and the redefinitions are pervasively applied to all the
> > components
> > > > in that
> > > > > clone. Note that if the schema being redefined has a null target
> > namespace,
> > > > it may
> > > > > be redefined in multiple schemas each with a different namespace and
> > each
> > > > in a
> > > > > different way; in this case, during incorporation, the namespace of
the
> > > > clone is
> > > > > modified to match the namespace of the redefining schema and the
other
> > > > redefinition
> > > > > modifications are applied as well. In any event, the original schema
> > remains
> > > > > untouched so that it can and will be reused in its pristine form when
> > > > referenced
> > > > > directly.
> > > >
> > > > > James Taylor wrote:
> > > >
> > > > > > Ed,
> > > > > >
> > > > > > Thank you for the explanation. It's not clear to me how
"pervasive"
> > the
> > > > > > W3C spec
> > > > > > ( http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#modify-s chema)
> > meant
> > > > > > a redefine to be when they state:
> > > > > >
> > > > > > The modifications have a pervasive impact, that is, only the
> > redefined
> > > > > > components are used, even when referenced from other
incorporated
> > > > > > components, whether redefined themselves or not.
> > > > > >
> > > > > > Given that later in the spec they imply that multiple redefines of
the
> > > > > > same type that conflict are not legal, I assume they meant that the
> > > > > > redefined type should "pervade" everywhere, including in my
example of
> > > > > > v4.xsd.
> > > > > >
> > > > > > James
> > > > > >
> > > > > > Ed Merks wrote:
> > > > > >
> > > > > > > James,
> > > > > >
> > > > > > > The v4.xsd schema isn't valid because its includes both a
redefined
> > > > version
> > > > > > of
> > > > > > > personName and addressee, via its include of v2.xsd's
redefinition of
> > > > > > v1.xsd, as
> > > > > > > well as the original version of personName and addressee, via its
> > > > include of
> > > > > > > v3.xsd's include of v1.xsd without redefinition. The v3.xsd
schema
> > > > needs to
> > > > > > > include v2.xsd not v1.xsd for this example to be valid. The
bottom
> > line
> > > > is
> > > > > > that
> > > > > > > v1.xsd is not modified by virtue of the redefine in v2.xsd; only
> > v2.xsd
> > > > sees
> > > > > > that
> > > > > > > redefinition directly and any schema importing or including
v2.xsd
> > will
> > > > see
> > > > > > that
> > > > > > > redefinition indirectly; but v3.xsd sees only the original
v1.xsd and
> > > > knows
> > > > > > nothing
> > > > > > > of v2.xsd. When we get to v4.xsd, the result is name collision.
> > > > > >
> > > > > > > James Taylor wrote:
> > > > > >
> > > > > > > > Ed,
> > > > > > > >
> > > > > > > > Thanks for the reply. My sample is below. In v4.xsd, I would
have
> > > > > > > > expected that the "marriedPeople" element would contain the
> > > > "generation"
> > > > > > > > element since it is redefined to include this in v2.xsd. The
> > > > > > > > "singlePeople" element does include the "generation" element as
> > > > expected.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > >
> > > > > > > > James
> > > > > > > >
> > > > > > > > v1.xsd:
> > > > > > > > <xs:schema
> > targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > > > elementFormDefault="unqualified"
> > attributeFormDefault="unqualified">
> > > > > > > > <xs:complexType name="personName">
> > > > > > > > <xs:sequence>
> > > > > > > > <xs:element name="title" type="xs:string" minOccurs="0"/>
> > > > > > > > <xs:element name="forename" type="xs:string" minOccurs="0"
> > > > > > > > maxOccurs="unbounded"/>
> > > > > > > > </xs:sequence>
> > > > > > > > </xs:complexType>
> > > > > > > >
> > > > > > > > <xs:element name="addressee" type="test:personName"/>
> > > > > > > > </xs:schema>
> > > > > > > >
> > > > > > > > v2.xsd:
> > > > > > > > <xs:schema
> > targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > > > elementFormDefault="unqualified"
> > attributeFormDefault="unqualified">
> > > > > > > > <xs:redefine schemaLocation="v1.xsd">
> > > > > > > > <xs:complexType name="personName">
> > > > > > > > <xs:complexContent>
> > > > > > > > <xs:extension base="test:personName">
> > > > > > > > <xs:sequence>
> > > > > > > > <xs:element name="generation" type="xs:string"
> > minOccurs="0"/>
> > > > > > > > </xs:sequence>
> > > > > > > > </xs:extension>
> > > > > > > > </xs:complexContent>
> > > > > > > > </xs:complexType>
> > > > > > > > </xs:redefine>
> > > > > > > >
> > > > > > > > <xs:element name="author" type="test:personName"/>
> > > > > > > > </xs:schema>
> > > > > > > >
> > > > > > > > v3.xsd:
> > > > > > > > <xs:schema
> > targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > > > elementFormDefault="unqualified"
> > attributeFormDefault="unqualified">
> > > > > > > > <xs:include schemaLocation="v1.xsd"/>
> > > > > > > >
> > > > > > > > <xs:complexType name="marriedPersonName">
> > > > > > > > <xs:complexContent>
> > > > > > > > <xs:extension base="test:personName">
> > > > > > > > <xs:sequence>
> > > > > > > > <xs:element name="maidenName" type="xs:string"
> > minOccurs="0"/>
> > > > > > > > </xs:sequence>
> > > > > > > > </xs:extension>
> > > > > > > > </xs:complexContent>
> > > > > > > > </xs:complexType>
> > > > > > > >
> > > > > > > > <xs:element name="marriedPerson"
type="test:marriedPersonName"/>
> > > > > > > >
> > > > > > > > </xs:schema>
> > > > > > > >
> > > > > > > > v4.xsd:
> > > > > > > > <xs:schema
> > targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > > > elementFormDefault="unqualified"
> > attributeFormDefault="unqualified">
> > > > > > > > <xs:include schemaLocation="v2.xsd"/>
> > > > > > > > <xs:include schemaLocation="v3.xsd"/>
> > > > > > > >
> > > > > > > > <xs:complexType name="people">
> > > > > > > > <xs:sequence>
> > > > > > > > <xs:element name="marriedPeople"
> > type="test:marriedPersonName"
> > > > > > > > maxOccurs="unbounded"/>
> > > > > > > > <xs:element name="singlePeople" type="test:personName"
> > > > > > > > maxOccurs="unbounded"/>
> > > > > > > > </xs:sequence>
> > > > > > > > </xs:complexType>
> > > > > > > > <xs:element name="directory" type="test:people"/>
> > > > > > > > </xs:schema>
> > > > > > > >
> > > > > > > > Ed Merks wrote:
> > > > > > > >
> > > > > > > > > James,
> > > > > > > >
> > > > > > > > > I'm not sure I can really answer the details of your
questions
> > > > without
> > > > > > clear
> > > > > > > > > references to particular components in actual schema
documents,
> > > > i.e., a
> > > > > > > > > sample. Perhaps it helps to explain that redefinition is
> > > > accomplished by
> > > > > > > > > making a clone of the schema being redefined and then
modifying
> > that
> > > > copy
> > > > > > > > > according to the redefinition. The original schema is not
> > touched;
> > > > it
> > > > > > may be
> > > > > > > > > redefined many times in many different ways. The schema
> > containing
> > > > the
> > > > > > > > > redefine will see only the copy, not the original. Which
version
> > you
> > > > get
> > > > > > will
> > > > > > > > > depend very much on where you ask, so you need to be
specific...
> > > > > > > >
> > > > > > > > > James Taylor wrote:
> > > > > > > >
> > > > > > > > > > Hello,
> > > > > > > > > > If I understand the W3C spec correctly, a redefined
complexType
> > > > should
> > > > > > be
> > > > > > > > > > used everywhere in place of the original type. For
example,
> > if I
> > > > use
> > > > > > the
> > > > > > > > > > redefined complexType as a base type for another type, the
> > derived
> > > > type
> > > > > > > > > > should now include the additional elements introduced by
the
> > > > redefined
> > > > > > > > > > type. This is not the behavior I'm seeing in Eclipse XSD.
> > When I
> > > > get
> > > > > > the
> > > > > > > > > > base type, using complexTypeDefinition.getBaseType(), I
> > continue
> > > > to get
> > > > > > > > > > the original definition instead of the redefined one.
> > References
> > > > to
> > > > > > the
> > > > > > > > > > type within the schema that has the redefine do point to
the
> > new
> > > > > > redefined
> > > > > > > > > > type, though. Is this intentional? Should I use a
different
> > > > > > mechanism to
> > > > > > > > > > get the base type? Or is this a bug?
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > >
> > > > > > > > > > James
Re: redefine [message #585325 is a reply to message #40755] Mon, 12 April 2004 10:44
 Ed MerksMessages: 31543Registered: July 2009 Senior Member
James,

Please open a bugzilla defect with a sample that illustrates the problem. I
believe that if you redefine a schema document that is composed by including other
schema documents, that the indirectly included documents won't see all the
redefinitions, so I suspect that the problem is avoidable if you put all the
contents into a single schema and redefine that schema.

James Taylor wrote:

> Ed,
>
> I believe I found a redefine bug. Complex types that are derived from
> types that are redefined continue to pick up the old type definition when
> these types are included. For example, in the case I showed below, if
> there was a Manager complexType with an Employee base type, the Manager
> type when used in the Company.xsd does not pick up the new "rank" element
> from the redefinition.
>
> Let me know if you'd rather I just file a bug that post this here. Thanks,
>
> James
>
> Ed Merks wrote:
>
> > James,
>
> > I think you need to show the example I showed below to get a clear answer to
> the
> > complete question. Multiple different redefines would normally cause a name
> > conflict, but not for the example below because the redefines are in
> different
> > namespaces and hence are redefining different abstract components. Unless
> someone
> > says the sample below is invalid and can point to some constraint in the
> spec that
> > would justify an error message for this case, then I will continue to
> consider the
> > case valid and will not make changes that would make that case stop working.
>
> > The case you show, modified as suggested in the answer to your question at
> the
> > schema forum, does work correctly now. Do you have cases without redundant
> (and
> > I'm still convinced, invalid) includes that don't work correctly?
>
> > James Taylor wrote:
>
> > > Ed,
> > >
> > > Thanks for fixing the bug you found and sorry about the error in
> > > Company.xsd. I sent a question to the W3C regarding redefines because I
> > > don't think the spec is as clear as it could be, and the answers I
> > > received clarify things:
> > >
> > > http://lists.w3.org/Archives/Public/xmlschema-dev/2004Mar/00 54.html
> > >
> > > I understand the revised example you've shown below is an alternative,
> > > however, it still should work the way I expressed it. The reason this is
> > > an important issue for us here at my company is that our schemas can
> > > become large with many levels of nesting. Being forced to redefine every
> > > encompassing type for all occurrences of a type becomes cumbersome and
> > > potentially error prone if an occurrence is missed. It can also prevents
> > > being able to redefine a type nested inside of element declaration with an
> > > anonymous type.
> > >
> > > I'll volunteer to fix it if that helps.
> > >
> > > James
> > >
> > > Ed Merks wrote:
> > > > James,
> > >
> > > > As I was fixing the Company.xsd to make it valid:
> > >
> > > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > > xmlns:test="http://namespaces.nextance.com/test"
> > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > >
> > > > <xs:redefine schemaLocation="Department.xsd">
> > > > <xs:complexType name="Employee">
> > > > <xs:complexContent>
> > > > <xs:extension base="test:Employee">
> > > > <xs:sequence>
> > > > <xs:element name="ranking" type="xs:int"/>
> > > > </xs:sequence>
> > > > </xs:extension>
> > > > </xs:complexContent>
> > > > </xs:complexType>
> > > > </xs:redefine>
> > >
> > > > <xs:complexType name="Company">
> > > > <xs:sequence>
> > > > <xs:element name="department" type="test:Department"
> > > > maxOccurs="unbounded"/>
> > > > <xs:element name="president" type="test:Employee"/>
> > > > </xs:sequence>
> > > > </xs:complexType>
> > >
> > > > <xs:element name="fortune500" type="test:Company"/>
> > >
> > > > </xs:schema>
> > >
> > > > I discovered that there is a bug that causes the transitive
> > > includes/redefines of a
> > > > cloned included/redefined schema to be omitted so I opened
> > > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=56328 and have fixed that
> > > particular
> > > > problem. So, to my way of thinking, the above sample is the correct way
> to
> > > express
> > > > what you intended.
> > >
> > > > Consider the following slightly modified example where Employee.xsd has
> no
> > > > namespace:
> > >
> > > > <xs:schema
> > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > <xs:complexType name="Employee">
> > > > <xs:sequence>
> > > > <xs:element name="name" type="xs:string"/>
> > > > </xs:sequence>
> > > > </xs:complexType>
> > > > </xs:schema>
> > >
> > > > and Department.xsd is still the same (but the include is changing the
> null
> > > > namespace of the included schema to match that of the including schema):
> > >
> > > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > > xmlns:test="http://namespaces.nextance.com/test"
> > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > <xs:include schemaLocation="Employee.xsd"/>
> > >
> > > > <xs:complexType name="Department">
> > > > <xs:sequence>
> > > > <xs:element name="employee" type="test:Employee"
> > > > maxOccurs="unbounded"/>
> > > > <xs:element name="manager" type="test:Employee"/>
> > > > </xs:sequence>
> > > > </xs:complexType>
> > > > </xs:schema>
> > >
> > > > In this case, a Company.xsd can validly access both the original version
> of
> > > > Employee as well as a redefined version.
> > >
> > > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > > xmlns:test="http://namespaces.nextance.com/test"
> > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > >
> > > > <xs:import schemaLocation="Employee.xsd"/>
> > >
> > > > <xs:redefine schemaLocation="Department.xsd">
> > > > <xs:complexType name="Employee">
> > > > <xs:complexContent>
> > > > <xs:extension base="test:Employee">
> > > > <xs:sequence>
> > > > <xs:element name="ranking" type="xs:int"/>
> > > > </xs:sequence>
> > > > </xs:extension>
> > > > </xs:complexContent>
> > > > </xs:complexType>
> > > > </xs:redefine>
> > >
> > > > <xs:complexType name="Company">
> > > > <xs:sequence>
> > > > <xs:element name="department" type="test:Department"
> > > > maxOccurs="unbounded"/>
> > > > <xs:element name="president" type="test:Employee"/>
> > > > <xs:element name="dummy" type="Employee"/>
> > > > </xs:sequence>
> > > > </xs:complexType>
> > >
> > > > <xs:element name="fortune500" type="test:Company"/>
> > >
> > > > </xs:schema>
> > >
> > > > The semantics view for this shows that everyone is using the redefined
> type,
> > > except
> > > > the junk element, which is using the original:
> > >
> > > > [Image]
> > >
> > > > This stuff is all really much too complicated for human minds to handle
> (and
> > > I
> > > > think there are still lurking bugs in the implementation, but I don't
> have
> > > any more
> > > > time to spend to look at this further).
> > >
> > > > James Taylor wrote:
> > >
> > > > > Ed,
> > > > >
> > > > > Here's a smaller more realistic example that illustrates an issue:
> > > > >
> > > > > File A defines Employee type
> > > > > File B includes File A and defines Department type
> > > > > File C includes File B, redefines Employee from File A and defines
> Company
> > > > > type
> > > > >
> > > > > This is a common use case for redefine in which a type in a nested
> include
> > > > > needs to be redefined. With Eclipse XSD, the redefine does not affect
> the
> > > > > Employee type within the Department type and affects the Employee type
> > > > > within the Company type only if the include of File B precedes the
> > > > > redefine of File A. This does not seem like the correct behavior.
> > > > >
> > > > > I've included the XSD files below. Thanks,
> > > > >
> > > > > James
> > > > >
> > > > > Employee.xsd:
> > > > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > > > xmlns:test="http://namespaces.nextance.com/test"
> > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > > <xs:complexType name="Employee">
> > > > > <xs:sequence>
> > > > > <xs:element name="name" type="xs:string"/>
> > > > > </xs:sequence>
> > > > > </xs:complexType>
> > > > > </xs:schema>
> > > > >
> > > > > Department.xsd:
> > > > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > > > xmlns:test="http://namespaces.nextance.com/test"
> > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > > <xs:include schemaLocation="Employee.xsd"/>
> > > > >
> > > > > <xs:complexType name="Department">
> > > > > <xs:sequence>
> > > > > <xs:element name="employee" type="test:Employee"
> > > > > maxOccurs="unbounded"/>
> > > > > <xs:element name="manager" type="test:Employee"/>
> > > > > </xs:sequence>
> > > > > </xs:complexType>
> > > > > </xs:schema>
> > > > >
> > > > > Company.xsd:
> > > > > <xs:schema targetNamespace="http://namespaces.nextance.com/test"
> > > > > xmlns:test="http://namespaces.nextance.com/test"
> > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > >
> > > > > <xs:include schemaLocation="Department.xsd"/>
> > > > >
> > > > > <xs:redefine schemaLocation="Employee.xsd">
> > > > > <xs:complexType name="Employee">
> > > > > <xs:complexContent>
> > > > > <xs:extension base="test:Employee">
> > > > > <xs:sequence>
> > > > > <xs:element name="ranking" type="xs:int"/>
> > > > > </xs:sequence>
> > > > > </xs:extension>
> > > > > </xs:complexContent>
> > > > > </xs:complexType>
> > > > > </xs:redefine>
> > > > >
> > > > > <xs:complexType name="Company">
> > > > > <xs:sequence>
> > > > > <xs:element name="department" type="test:Department"
> > > > > maxOccurs="unbounded"/>
> > > > > <xs:element name="president" type="test:Employee"/>
> > > > > </xs:sequence>
> > > > > </xs:complexType>
> > > > >
> > > > > <xs:element name="fortune500" type="test:Company" maxOccurs="500"/>
> > > > >
> > > > > </xs:schema>
> > > > >
> > > > > Ed Merks wrote:
> > > > >
> > > > > > James,
> > > > >
> > > > > > All the components of the schema mentioned in the redefine are
> > > incorporated
> > > > > (i.e.,
> > > > > > cloned) and the redefinitions are pervasively applied to all the
> > > components
> > > > > in that
> > > > > > clone. Note that if the schema being redefined has a null target
> > > namespace,
> > > > > it may
> > > > > > be redefined in multiple schemas each with a different namespace and
> > > each
> > > > > in a
> > > > > > different way; in this case, during incorporation, the namespace of
> the
> > > > > clone is
> > > > > > modified to match the namespace of the redefining schema and the
> other
> > > > > redefinition
> > > > > > modifications are applied as well. In any event, the original schema
> > > remains
> > > > > > untouched so that it can and will be reused in its pristine form when
> > > > > referenced
> > > > > > directly.
> > > > >
> > > > > > James Taylor wrote:
> > > > >
> > > > > > > Ed,
> > > > > > >
> > > > > > > Thank you for the explanation. It's not clear to me how
> "pervasive"
> > > the
> > > > > > > W3C spec
> > > > > > > ( http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#modify-s chema)
> > > meant
> > > > > > > a redefine to be when they state:
> > > > > > >
> > > > > > > The modifications have a pervasive impact, that is, only the
> > > redefined
> > > > > > > components are used, even when referenced from other
> incorporated
> > > > > > > components, whether redefined themselves or not.
> > > > > > >
> > > > > > > Given that later in the spec they imply that multiple redefines of
> the
> > > > > > > same type that conflict are not legal, I assume they meant that the
> > > > > > > redefined type should "pervade" everywhere, including in my
> example of
> > > > > > > v4.xsd.
> > > > > > >
> > > > > > > James
> > > > > > >
> > > > > > > Ed Merks wrote:
> > > > > > >
> > > > > > > > James,
> > > > > > >
> > > > > > > > The v4.xsd schema isn't valid because its includes both a
> redefined
> > > > > version
> > > > > > > of
> > > > > > > > personName and addressee, via its include of v2.xsd's
> redefinition of
> > > > > > > v1.xsd, as
> > > > > > > > well as the original version of personName and addressee, via its
> > > > > include of
> > > > > > > > v3.xsd's include of v1.xsd without redefinition. The v3.xsd
> schema
> > > > > needs to
> > > > > > > > include v2.xsd not v1.xsd for this example to be valid. The
> bottom
> > > line
> > > > > is
> > > > > > > that
> > > > > > > > v1.xsd is not modified by virtue of the redefine in v2.xsd; only
> > > v2.xsd
> > > > > sees
> > > > > > > that
> > > > > > > > redefinition directly and any schema importing or including
> v2.xsd
> > > will
> > > > > see
> > > > > > > that
> > > > > > > > redefinition indirectly; but v3.xsd sees only the original
> v1.xsd and
> > > > > knows
> > > > > > > nothing
> > > > > > > > of v2.xsd. When we get to v4.xsd, the result is name collision.
> > > > > > >
> > > > > > > > James Taylor wrote:
> > > > > > >
> > > > > > > > > Ed,
> > > > > > > > >
> > > > > > > > > Thanks for the reply. My sample is below. In v4.xsd, I would
> have
> > > > > > > > > expected that the "marriedPeople" element would contain the
> > > > > "generation"
> > > > > > > > > element since it is redefined to include this in v2.xsd. The
> > > > > > > > > "singlePeople" element does include the "generation" element as
> > > > > expected.
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > >
> > > > > > > > > James
> > > > > > > > >
> > > > > > > > > v1.xsd:
> > > > > > > > > <xs:schema
> > > targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > > > > elementFormDefault="unqualified"
> > > attributeFormDefault="unqualified">
> > > > > > > > > <xs:complexType name="personName">
> > > > > > > > > <xs:sequence>
> > > > > > > > > <xs:element name="title" type="xs:string" minOccurs="0"/>
> > > > > > > > > <xs:element name="forename" type="xs:string" minOccurs="0"
> > > > > > > > > maxOccurs="unbounded"/>
> > > > > > > > > </xs:sequence>
> > > > > > > > > </xs:complexType>
> > > > > > > > >
> > > > > > > > > <xs:element name="addressee" type="test:personName"/>
> > > > > > > > > </xs:schema>
> > > > > > > > >
> > > > > > > > > v2.xsd:
> > > > > > > > > <xs:schema
> > > targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > > > > elementFormDefault="unqualified"
> > > attributeFormDefault="unqualified">
> > > > > > > > > <xs:redefine schemaLocation="v1.xsd">
> > > > > > > > > <xs:complexType name="personName">
> > > > > > > > > <xs:complexContent>
> > > > > > > > > <xs:extension base="test:personName">
> > > > > > > > > <xs:sequence>
> > > > > > > > > <xs:element name="generation" type="xs:string"
> > > minOccurs="0"/>
> > > > > > > > > </xs:sequence>
> > > > > > > > > </xs:extension>
> > > > > > > > > </xs:complexContent>
> > > > > > > > > </xs:complexType>
> > > > > > > > > </xs:redefine>
> > > > > > > > >
> > > > > > > > > <xs:element name="author" type="test:personName"/>
> > > > > > > > > </xs:schema>
> > > > > > > > >
> > > > > > > > > v3.xsd:
> > > > > > > > > <xs:schema
> > > targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > > > > elementFormDefault="unqualified"
> > > attributeFormDefault="unqualified">
> > > > > > > > > <xs:include schemaLocation="v1.xsd"/>
> > > > > > > > >
> > > > > > > > > <xs:complexType name="marriedPersonName">
> > > > > > > > > <xs:complexContent>
> > > > > > > > > <xs:extension base="test:personName">
> > > > > > > > > <xs:sequence>
> > > > > > > > > <xs:element name="maidenName" type="xs:string"
> > > minOccurs="0"/>
> > > > > > > > > </xs:sequence>
> > > > > > > > > </xs:extension>
> > > > > > > > > </xs:complexContent>
> > > > > > > > > </xs:complexType>
> > > > > > > > >
> > > > > > > > > <xs:element name="marriedPerson"
> type="test:marriedPersonName"/>
> > > > > > > > >
> > > > > > > > > </xs:schema>
> > > > > > > > >
> > > > > > > > > v4.xsd:
> > > > > > > > > <xs:schema
> > > targetNamespace="http://namespaces.nextance.com/nex/test"
> > > > > > > > > xmlns:test="http://namespaces.nextance.com/nex/test"
> > > > > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > > > > > > > elementFormDefault="unqualified"
> > > attributeFormDefault="unqualified">
> > > > > > > > > <xs:include schemaLocation="v2.xsd"/>
> > > > > > > > > <xs:include schemaLocation="v3.xsd"/>
> > > > > > > > >
> > > > > > > > > <xs:complexType name="people">
> > > > > > > > > <xs:sequence>
> > > > > > > > > <xs:element name="marriedPeople"
> > > type="test:marriedPersonName"
> > > > > > > > > maxOccurs="unbounded"/>
> > > > > > > > > <xs:element name="singlePeople" type="test:personName"
> > > > > > > > > maxOccurs="unbounded"/>
> > > > > > > > > </xs:sequence>
> > > > > > > > > </xs:complexType>
> > > > > > > > > <xs:element name="directory" type="test:people"/>
> > > > > > > > > </xs:schema>
> > > > > > > > >
> > > > > > > > > Ed Merks wrote:
> > > > > > > > >
> > > > > > > > > > James,
> > > > > > > > >
> > > > > > > > > > I'm not sure I can really answer the details of your
> questions
> > > > > without
> > > > > > > clear
> > > > > > > > > > references to particular components in actual schema
> documents,
> > > > > i.e., a
> > > > > > > > > > sample. Perhaps it helps to explain that redefinition is
> > > > > accomplished by
> > > > > > > > > > making a clone of the schema being redefined and then
> modifying
> > > that
> > > > > copy
> > > > > > > > > > according to the redefinition. The original schema is not
> > > touched;
> > > > > it
> > > > > > > may be
> > > > > > > > > > redefined many times in many different ways. The schema
> > > containing
> > > > > the
> > > > > > > > > > redefine will see only the copy, not the original. Which
> version
> > > you
> > > > > get
> > > > > > > will
> > > > > > > > > > depend very much on where you ask, so you need to be
> specific...
> > > > > > > > >
> > > > > > > > > > James Taylor wrote:
> > > > > > > > >
> > > > > > > > > > > Hello,
> > > > > > > > > > > If I understand the W3C spec correctly, a redefined
> complexType
> > > > > should
> > > > > > > be
> > > > > > > > > > > used everywhere in place of the original type. For
> example,
> > > if I
> > > > > use
> > > > > > > the
> > > > > > > > > > > redefined complexType as a base type for another type, the
> > > derived
> > > > > type
> > > > > > > > > > > should now include the additional elements introduced by
> the
> > > > > redefined
> > > > > > > > > > > type. This is not the behavior I'm seeing in Eclipse XSD.
> > > When I
> > > > > get
> > > > > > > the
> > > > > > > > > > > base type, using complexTypeDefinition.getBaseType(), I
> > > continue
> > > > > to get
> > > > > > > > > > > the original definition instead of the redefined one.
> > > References
> > > > > to
> > > > > > > the
> > > > > > > > > > > type within the schema that has the redefine do point to
> the
> > > new
> > > > > > > redefined
> > > > > > > > > > > type, though. Is this intentional? Should I use a
> different
> > > > > > > mechanism to
> > > > > > > > > > > get the base type? Or is this a bug?
> > > > > > > > > > >
> > > > > > > > > > > Thanks,
> > > > > > > > > > >
> > > > > > > > > > > James

Ed Merks
Professional Support: https://www.macromodeling.com/
 Previous Topic: schema loading problems Next Topic: URI converting - set resource base
Goto Forum:

Current Time: Fri Oct 23 12:05:39 GMT 2020

Powered by FUDForum. Page generated in 0.04029 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software