anchor.diff:  </receive>
   ----
   
  -The *schema-repository* attribute refers to a Citrus schema repository component which is defined somewhere in the Spring application context.
  -
  -IMPORTANT: In case you have several schema repositories in your project do always define a default repository (name="schemaRepository"). This helps Citrus to always find at least one repository to interact with.
  +The *schema-repository* attribute refers to a Citrus schema repository component which is defined somewhere in the
  +Spring application context.
  +
  +IMPORTANT: In case you have several schema repositories in your project do always define a default repository
  +(name="schemaRepository"). This helps Citrus to always find at least one repository to interact with.
   
   [[dtd-validation]]
   ==== DTD validation
   
  -XML DTD (document type definition) is another way to validate the structure of a XML document. Many people say that DTD is deprecated and XML schema is the much more efficient way to describe the rules of a XML structure. We do not disagree with that, but we also know that legacy systems might still use DTD. So in order to avoid validation errors we have to deal with DTD validation as well.
  +XML DTD (document type definition) is another way to validate the structure of a XML document. Many people say that
  +DTD is deprecated and XML schema is the much more efficient way to describe the rules of a XML structure. We do not
  +disagree with that, but we also know that legacy systems might still use DTD. So in order to avoid validation errors
  +we have to deal with DTD validation as well.
   
   First thing you can do about DTD validation is to specify an inline DTD in your expected message template.
   
  
positive.code: </bean>
  ----
  
  So the schema mapping chain uses both *RootQNameSchemaMappingStrategy* and *TargetNamespaceSchemaMappingStrategy* in combination. In case the first root qname strategy fails to find a proper mapping the next target namespace strategy comes in and tries to find a proper schema.
  
  [[schema-definition-overruling]]
  ==== Schema definition overruling
  
  Now it is time to talk about schema definition settings on test action level. We have learned before that Citrus tries to automatically find a matching schema definition in some schema repository. There comes a time where you as a tester just have to pick the right schema definition by yourself. You can overrule all schema mapping strategies in Citrus by directly setting the desired schema in your receiving message action.
  
  [source,xml]
  ----
  
negative.code:       location="classpath:citrus/flightbooking/SmartAirlineSchema.xsd"/>
  ----
  
  By convention there is a default schema repository component defined in the Citrus Spring application context with
  the id *schemaRepository*. Spring application context is then able to inject the schema repository into all message
  receiving test actions at runtime. The receiving test action consolidates the repository for a matching schema
  definition file in order to validate the incoming XML document structure.
  
  The connection between incoming XML messages and xsd schema files in the repository is done by a mapping strategy which
  we will discuss later in this chapter. By default Citrus picks the right schema based on the target namespace that is
  defined inside the schema definition. The target namespace of the schema definition has to match the namespace of the
  root element in the received XML message. With this mapping strategy you will not have to wire XML messages and schema
  files manually all is done automatically by the Citrus schema repository at runtime. All you need to do is to register
  all available schema definition files regardless of which target namespace or nature inside the Citrus schema
  repository.
  
  IMPORTANT: XML schema validation is mandatory in Citrus. This means that Citrus always tries to find a matching schema
  definition inside the schema repository in order to perform syntax validation on incoming schema qualified XML messages.
  A classified XML message is defined by its namespace definitions. Consequently you will get validation errors in case
  no matching schema definition file is found inside the schema repository. So if you explicitly do not want to validate
  the XML schema for some reason you have to disable the validation explicitly in your test with
  *schema-validation="false"*.
  
  [source,xml]
  ----
  