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

This means that to create an element holding a sequence of
IDREF
values, you write:

whereas to declare a variable holding the same sequence, you write:

In the case of

, note that the option
validation = “preserve”
applies to the children (and attributes) of the copied element, but not to the copied element itself. This instruction does a shallow copy, so in general the content of the new element will be completely different from the content of the old one. It doesn't make sense to keep the type annotation intact if the content is changing, because this could result in the type annotation becoming inconsistent with the actual content.

By contrast, the

instruction does a deep copy. Because the content remains unchanged, it's safe to keep the type annotation unchanged, and the option
validation = “preserve”
is useful in achieving this.

When you request validation at the element level, the system does not perform any document-level integrity checks. That is, it does not check that
ID
values are unique, or that
IDREF
values don't point into thin air. To invoke this level of validation, you have to do it at the document level. The specification as published also says that it does not check identity constraints defined by

,

, and

definitions in the schema, but this was a mistake and has been fixed in an erratum.

Validating Individual Attributes

XSLT 2.0 also allows you to request validation at the level of individual attributes. The

instruction, like

, has attributes
validation
and
type
, which can be used to validate an attribute node independently of its containing element.

It's relatively unusual for a schema to contain global attribute declarations, so the options
validation = “strict”
and
validation = “lax”
are unlikely to be very useful at the attribute level. Also, because attributes don't have children, the options
validation = “strip”
and
validation = “preserve”
both mean the same thing: the new attribute node will be annotated as
xs:untypedAtomic
. The most useful option for attributes is to specify
type
to validate the attribute value against a specific type definition in the schema. This will always be the name of a simple type, and in many cases it will be the name of a built-in atomic type, for example
type = “xs:date”