XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition (162 page)

Validating an element using the
type
attribute places no constraints on the name of the element. It does not need to be an element name that is defined in any schema. The validation is concerned with the content of the element (including, of course, the names of its attributes and children) and not with its name.

In contrast, validation using the
validation
attribute is driven by the element's name.

There are two options for the
validation
attribute that cause schema validation to happen and two options that cause it not to happen. Let's take the last two first:

• validation=“preserve”
  means that the new element will have a type annotation of
  xs:anyType
  , and the attributes and elements in its content will have their original type annotation. During the (formal) process of copying nodes from the sequence produced by evaluating the sequence constructor, the nodes are copied with their type annotations intact.
  
• validation=“strip”
  means that the new element will have a type annotation of
  xs:untyped
  , and in this case the attributes and elements in its content (at any depth) will have their type annotation changed to
  xs:untypedAtomic
  or
  xs:untyped
  , respectively. (The type annotations are changed in the course of copying the nodes; the original nodes are, of course, unchanged).
  

The difference between
xs:anyType
and
xs:untyped
is rather subtle, and most applications won't notice the difference. However, the XSLT processor knows when it sees an
xs:untyped
element that all its descendants will also be
xs:untyped
, and this makes certain optimizations possible.

The other two options are
strict
and
lax
:

• validation=“strict”
  causes the processor to look in the schema for an element declaration that matches the name of the element. That is, it looks for a top-level
  
  whose
  name
  attribute matches the local name of the element being validated, in a schema document whose target namespace matches the namespace URI of the element being validated. If it can't find such a definition, a fatal error is reported. Otherwise, the content of the element is validated against the schema-defined rules implied by this element declaration.
  

  If the element declaration in the schema refers to a named type definition, then on successful validation, the element is annotated with this type name. If the element declaration contains an inline (and therefore unnamed) type definition, the XSLT processor invents a name for this implicit type, and uses this invented name as the type annotation, just as in the case described earlier for the
  type
  attribute.
  

  If the element declaration requires it, then strict validation of an element proceeds recursively through the content of the element. It is possible, however, that the element declaration is liberal. It may, for example, define the permitted contents of the element using
  
  , with
  processContents
  set to
  lax
  or
  skip
  . In this case, validation follows the schema rules. If
  skip
  is specified, for example, the relevant subtree is not validated. All nodes in such a subtree will be annotated as if
  validation=“strip”
  were specified.
  

  If an
  xsi:type
  attribute appears in the data being validated, then the system takes account of it according to the rules in the XML Schema specification. Elements validated against such an attribute will end up with this type as their type annotation.
  

• validation=“lax”
  behaves in the same way as
  validation=“strict”
  , except that no failure occurs if the processor cannot locate a top-level schema declaration for the element. Instead of reporting an error, the element is annotated as
  xs:anyType
  , and validation continues recursively (again, in lax mode) with its attributes and child elements. Once an element is found that does have a schema definition, however, it is validated strictly against that definition, and if validation fails, a fatal error is reported.