Question

The question in short – “can I define a schema within a schema which can be validated as a whole?

Explanation:

Is it possible to define a schema for the following XML. I need to define a schema for “customer”. The “customertype” child element itself is a schema. Within the customertype I should have an element called “Source” which is mandatory.

 <customer>
    <customername>acustomer</customername>
    <customertype>
      <xs:schema>
      <xs:element name="profession">
         <xs:complexType>
              <xs:sequence>
                 <xs:element name="Source" type="xs:int" />
                 <xs:element name="ProfessionName" type="xs:string" />
             </xs:sequence>
          </xs:complexType>     
         </xs:schema>
      </customertype>
  </customer>

Is it possible to Define the schema for this xml so that all the requirements are met?

Answer 1

As Mimo has pointed out, there’s no problem defining customertype (or another other element) as containing elements in the XSD namespace, which is what you appear to be asking about.

But if your goal is to be able to validate customer elements (or profession elements, which is what the schema in your example declares), it’s hard to imagine a validation architecture in which that’s the best way (or even a workable way) to go about it. One reason is that validating a document instance against schema information provided by the instance being validated doesn’t produce the same confidence in the data’s cleanliness as validating it against a known schema. (Put yourself in the shoes of an adversary seeking to subvert your validation and persuade your system to accept bogus data as valid. If the adversary gets to specify what counts as a valid document instance, how useful is it to know that the document is valid?)

What is it that prevents you from writing a schema and using it in the usual way?

[Addition, 15 October 2012, after OP’s comment]

If I’ve understood your comment of earlier today correctly, your requirement is to allow people other than you to specify the type of the customer element however they like, subject to the proviso that that type must contain a child element named Source, whose type will be xsd:int. You don’t specify whether you need access to the type definition they are using or not, so I’ll try to consider both the case where you do need it and the case where you don’t need it.

Three ways to make this situation work are described below. They have in common that there is

• a ‘main’ schema document that defines a basic version of the schema, and
• one or more ‘auxiliary’ schema documents for use in different situations.

In general, you may find it helpful to find a good textbook on XSD and review what it says about creating a schema from declarations in several schema documents.

(1) One approach uses xsi:type. You define a main schema document in which the customer element has a named type; I’ll assume the type is named Customer. The Customer type accepts any element whose first child element is named Source. For example:

<xs:element name="customer" type="Customer"/>
<xs:complexType name="Customer">
  <xs:sequence>
    <xs:element name="Source" type="xs:int"/>
    <xs:any minOccurs="0" 
            maxOccurs="unbounded" 
            processContents="lax"/>
  </xs:sequence>
  <xs:anyAttribute processContents="lax"/>
</xs:complexType>

Those who want a more specific type for the customer element (I’ll call them the ‘users’) provide auxiliary schema documents for your target namespace in which they declare other complex types which restrict Customer. For example, they might want the customer element to contain elements called name, address, and phone number:

<xs:complexType name="Customer-for-us">
  <xs:complexContent>
    <xs:restriction base="Customer">
      <xs:sequence>
        <xs:element name="Source" type="xs:int"/>
        <xs:element ref="name"/>
        <xs:element ref="address"/>
        <xs:element ref="phone"/>
      </xs:sequence>
    </xs:restriction>
  </xs:complexContent>
</xs:complexType>

This is a legal restriction of the Customer type, so the customer element can use it. A document instance might therefore contain an element like:

<customer xsi:type="Customer-for-us">
  <Source>83760273</Source>
  <name>Willy Wonka</name>
  <address> ... </address>
  <phone> ... </phone>
</customer>

The document is validated against the schema constructed from their auxiliary schema document, together with the main schema document, so the definition of type Customer-for-us is enforced in the usual way.

By using wildcards and lax validation, the Customer type ensures that users can do anything they like in their version of the type, as long as the first child is named Source and has type int.

(2) A second approach uses a hole in the main schema document.

You write a main schema document as before, including the declaration of the customer element as having type Customer. But the main schema document does not contain a declaration for that type. Instead, you declare the Customer type in an auxiliary schema document, which is combined with the main one at validation time in the usual way (I’d recommend you have a third schema document which serves as a driver and includes the other two, but there are many ways to make it work).

The users who want a more specific Customer type, meanwhile, write their own declaration for the Customer type, subject to the compatibility constraints about the first child named Source and so on. The users use their own driver file, which embeds the main schema document and their version of the auxiliary schema document with their own declaration of the Customer type.

This way, the xsi:type attribute does not need to be used.

(3) A third approach uses the xs:redefine or (in XSD 1.1) the xs:override facility.

You write the main schema document as described in solution (1). The users use xs:redefine or xs:override to redefine Customer as they wish. This answer is already rather long, so I do not propose to include a tutorial on the use of either redefine or override.