Cardinality

All indicator

The <all> indicator specifies that the child elements can appear in any order, and that each child element must occur only once.

<xs:element name="person">
 <xs:complexType>
  <xs:all>
   <xs:element name="firstname" type="xs:string"/>
   <xs:element name="lastname" type="xs:string"/>
  </xs:all>
  </xs:complexType>
</xs:element>

Choice indicator

The <choice> indicator specifies that either one child element or another can occur.

<xs:element name="person">
 <xs:complexType>
  <xs:choice>
    <xs:element name="employee" type="employee"/>
    <xs:element name="member" type="member"/>
   </xs:choice>
  </xs:complexType>
</xs:element>

Sequence indicator

The <sequence> indicator specifies that the child elements must appear in a specific order.

<xs:element name="person">
 <xs:complexType>
  <xs:sequence>
    <xs:element name="firstname" type="xs:string"/>
    <xs:element name="lastname" type="xs:string"/>
   </xs:sequence>
  </xs:complexType>
</xs:element>

From a Talend MDM perspective, the order indicators that are generally used are All and Sequence. It is possible to use Choice, but it is rare to find MDM scenarios that can use it.

You should define the order indicators at this step because they are directly linked to a discussion on cardinality. By default, when you create an entity in Talend MDM, the anonymous type of the entity has an order indicator of All.

This is important because any element that you define within this entity can be sent to Talend MDM in any order. For this example, you can send the following XML to create a new 'newEntity' record in your MDM.

<newEntity> 
         <stuff>hello</stuff>
         <moreStuff>world</moreStuff>
</newEntity>

Or you could sent the XML as:

<newEntity> 
         <moreStuff>world</moreStuff>
         <stuff>hello</stuff>
</newEntity>

The order of the elements 'stuff' and 'moreStuff' is not important.

Here is what happens when you change the cardinality of the 'stuff' element from 0...1 to 0...many:

Now you can have more than one 'stuff', but all elements in the entity have to be supplied in the correct sequence.

<newEntity> 
         <stuff>hello</stuff>
         <moreStuff>world</moreStuff>
</newEntity>

The example above would be valid.

<newEntity> 
         <stuff>hello</stuff>
         <stuff>hi</stuff>
         <moreStuff>world</moreStuff>
</newEntity>

The example above would also be valid.

<newEntity> 
         <moreStuff>world</moreStuff>
         <stuff>hello</stuff>
</newEntity>

The example above would be invalid, due to the order of the elements. From an integration perspective, defining the loop (the repeating element) at the root entity level means you have to be incredibly precise in your integration logic. It can also mean that the integration logic is difficult to read and to understand, especially when you have more than one repeating element.

As defined earlier in this article, it is better to encapsulate your repeating elements within parent complex types.

Single repeating element:

Repeating complex type:

If you do this, the root anonymous type of your entity can use the order indicator All (no restriction on order) and only the elements (not their children) within the repeating loop are constrained by a sequence.

Finally, in the party/phone example above, you can examine the cardinality of the child elements of 'phoneNumberItem'. You can see that the three elements 'number', 'type', and 'marketingOk' are all configured with a cardinality of 1...1. However, examine the cardinality of the 'phoneNumberItem' and 'phoneNumberList' elements: these are optional. This means that:

• If you supply no data for phone numbers, the entity will validate.
• If you want to supply one or more phone numbers ('number'), the fields 'type' and 'marketingOk' would also be required, otherwise the entity would be invalid.