Question

I think what I need to do it's not possible with XSD 1.0, but anyway I'll ask... I have a complexType in a file, say a.xsd. In principle, I cannot touch this file. In particular, I cannot change its targetNamespace. An example would be:

<xs:schema targetNamespace="http://myns.original" 
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:orig="http://myns.original">

  <xs:element name="config" type="orig:ConfigType"/>

  <xs:complexType name="ConfigType">
    <xs:sequence>
      <xs:element name="fieldA" type="xs:integer" minOccurs="0"/>
    </xs:sequence>
  </xs:complexType>

</xs:schema>

I have a second file, b.xsd, where I extend a type defined in a.xsd, and redefine an element previously defined in a.xsd, by using substitutionGroup. Everything is fine for now, and the following example seems to be OK:

<xs:schema targetNamespace="http://myns.myns" 
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:myns="http://myns.myns" xmlns:orig="http://myns.original">

  <xs:import namespace="http://myns.original" schemaLocation="a.xsd"/>

  <xs:complexType name="ConfigType">
    <xs:complexContent>
      <xs:extension base="orig:ConfigType">
        <xs:sequence>
          <xs:element name="fieldB" type="xs:string"/>
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

  <xs:element name="config" type="myns:ConfigType" substitutionGroup="orig:config"/>

</xs:schema>

Problems are coming: one field in the original complexType is optional (minOccurs=0). Now, I need to redefine this type so that that field is mandatory (minOccurs=1). I guessed this could be achieved with xsd:redefine, so I tried the following:

<xs:schema targetNamespace="http://myns.myns" 
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:myns="http://myns.myns">

  <xs:redefine schemaLocation="b.xsd">

    <xs:complexType name="ConfigType">
      <xs:complexContent>
        <xs:restriction base="myns:ConfigType">
          <xs:sequence>
            <xs:element name="fieldA" minOccurs="1"/>
          </xs:sequence>
        </xs:restriction>
      </xs:complexContent>
    </xs:complexType>

  </xs:redefine>

</xs:schema>

But I get the following messages:

 There is not a complete functional mapping between the particles.
 Error for type 'ConfigType'.  The particle of the type is not a valid restriction of the particle of the base.

Honestly, I do not quite understand these messages, but after some investigation, it seems that the actual problem is that the redefined fields must belong to the very same namespace as the redefinition. In my case, I try to restrict the field orig:fieldA, within the namespace http://myns.original, in a file with the targetNamespace="http://myns.myns". Of course, if a keep extending the type in c.xsd as I did in b.xsd, there is no problem, since I do not try to modify anything from a different namespace.

Does anybody know if this can be achieved? One solution is to replicate the definitions that would be modified in a different file, a_2.xsd, with the right targetNamespace. But this is a highly undesired and unmaintainable solution for a complex system.

Was it helpful?

Solution

The only problem I see so far is that in schema a.xsd you have defined:

<xs:element name="fieldA" type="xs:integer" minOccurs="0"/>

whereas in the last schema (redefinition), you have:

<xs:element name="fieldA" minOccurs="1"/>

What the last declaration actually means is that you implicitly specify xs:anyType for the fieldA:

<xs:element name="fieldA" type="xs:anyType" minOccurs="1"/>

Remember that when you derive a new type by restriction (which is actually what you do in the redefinition), you must define the element content model entirely anew. But that new content model must fully comply with the old one.

That's not the case in your last schema, because previously according to a.xsd, the element fieldA was allowed to have only integer value. But now, you say it may accept anything. That would certainly cause an error, and the message you received (although rather gibberish indeed):

The particle of the type is not a valid restriction of the particle of the base.

seems to be saying exactly about this.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top