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

BOOK: XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition

8.15Mb size Format: txt, pdf, ePub

ads

The following examples illustrate the effect:

Instruction	Result
select=“1 to 5”/>	x=“1 2 3 4 5”
	x=“12345”
select=“1 to 5” separator=“,”/>	x=“1 , 2 , 3 , 4 , 5”
separator=“-”>	x=“1-2-3-4-5”
	x=“12345” There is no separator here because adjacent text nodes are merged before separators are added .

In XSLT 1.0, it was an error if evaluating the content of an attribute produced a node other than a text node. Processors were allowed to recover by ignoring such nodes. In XSLT 2.0, any kind of node is allowed and is handled by the atomization process. If your stylesheet contains this error, and your XSLT 1.0 processor chose to ignore it, then it will produce different results under XSLT 2.0.

Validating and Annotating the Attribute

This section is relevant only if you are using a schema-aware XSLT processor. With a non-schema-aware processor, you cannot use the
type
and
validation
attributes, and the type annotation on the new attribute node will always be
xs:untypedAtomic
, which you can effectively ignore because it imposes no constraints. This will also be the result with a schema-aware processor if you omit these two attributes.

With a schema-aware processor, you can validate the new attribute to ensure that it conforms to relevant definitions in a schema. If validation fails, a fatal error is reported. If it succeeds, the new attribute node will have a type annotation that reflects the validation that was performed. This type annotation will not affect the way the attribute node is serialized, but if you want to do further processing on the attribute, the type annotation may affect the way this works. For example, if you sort a sequence of attributes annotated with type
xs:integer
, you will get different results than if they are annotated as
xs:string
.

If you use the
type
attribute, its value must be a lexical QName that identifies a known type definition. Generally, this means that it must either be a built-in type such as
xs:string
or
xs:dateTime
, or it must be the name of a global simple type defined in a schema that has been imported using an

declaration in the stylesheet. (That is, the local part of the QName must match the
name
attribute of a top-level

element in a schema document whose target namespace matches the namespace URI part of the QName.)

The XSLT specification allows the implementation to provide other ways of accessing type definitions, perhaps through an API or configuration file, and it also allows the type definition to originate from a source other than an XML Schema document, but since it provides no details of how this might work, we won't explore the possibility further.

The processor validates that the value of the new attribute node conforms to the named type definition. If it does, the attribute is annotated with the name of this type. If it doesn't, processing fails.

Validating an attribute using the
type
attribute places no constraints on the name of the attribute. It doesn't need to be an attribute name that is defined in any schema, and it doesn't matter whether or not the attribute name is in a namespace. The validation is concerned with the content of the attribute and not with its name.

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

For symmetry with other instructions, the
validation
attribute has four possible values:
preserve
,
strip
,
strict
, and
lax
. However, in the case of

,
preserve
and
strip
have exactly the same effect: No validation takes place, and the type annotation on the attribute node will be
xs:untypedAtomic
. Let's focus on the other two options.