[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

[xsl] XSLT 2.0 types [was RE: [xsl] Comparing node for identity using union]

Subject: [xsl] XSLT 2.0 types [was RE: [xsl] Comparing node for identity using union]
From: "Michael Kay" <mike@xxxxxxxxxxxx>
Date: Wed, 19 Jan 2005 19:32:56 -0000

> Maybe there is already a resource out there, but I can't seem 
> to find a
> simple explanation.  Maybe because its not so simple?

It's not that simple, certainly not with 2.0 when schemas start to come into
the picture.

I've covered it in my XPath 2.0 and XSLT 2.0 books, and it's certainly not
easy to condense into a quick message. But let's try a summary:

The value of an XPath expression is always a sequence; a sequence contains
zero or more items; an item may be an atomic value or a node.

The nodes fall into the same 7 kinds as XPath 1.0: elements, attributes,
text nodes, etc.

Atomic values belong to one of the primitive types defined in XML Schema:
xs:integer, xs:string, xs:boolean, xs:date, and so on. Alternatively they
may belong to a derived atomic type, which permits a subset of the values of
a primitive type (e.g. all strings of length 6). This can be a user-defined
type defined in a schema, or a built-in type.

If your source document has been through schema validation, then the
elements and attributes will be annotated with a schema type. This may be a
simple type or (in the case of elements) a complex type. For example, an
attribute annotated as xs:date contains a date. Complex types allow child
elements, simple types do not. Simple types may be atomic types (as above)
or they may be list types (a sequence of integers, say) or union types (a
decimal or a date). When in XPath you use a node in a context where atomic
values are expected, e.g. comparison or arithmetic, the typed value of the
node is extracted automatically (a process called atomization). This means
that if your schema declares attributes to be numbers, they will be
processed as numbers.

You can declare the types of all the variables and parameters, function
results etc in your stylesheet. You don't have to: the default is item()*
which allows any value (any sequence of any items). For example, if you
declare a parameter as xs:integer? then the value must be either an integer
or nothing (an empty sequence). Where the variable holds nodes, you can
declare both the kind of node and the required type annotation: for example
a parameter that's an element holding a purchase order might be declared

You can write XSLT templates based on types rather than names, for example
match="attribute(*, xs:date)" matches all attributes of type date. So you
can write one rule for formatting all such attributes, regardless of their

When your stylesheet constructs new elements, you can ask for them to be
validated against a schema. This both checks them for correctness, and
annotates them with types that are used in any subsequent processing. You do
this using the validation and/or type attributes on instructions such as
xsl:element and xsl:result-document. This means for example that if your
stylesheet fails to output a value for a mandatory attribute, you'll get an
error message saying so, and telling you exactly where the error in the
stylesheet is. In some cases you'll even get this error at stylesheet
compile time.

You can ignore most of this and do dynamic typing as in XSLT 1.0 if you
prefer. But there are considerable software engineering advantages in
declaring your types: it means you get better error messages when you make
mistakes. In general, if you make coding errors in XSLT 1.0, your stylesheet
produces wrong output. The same mistake in 2.0 will often produce type
errors, reported often at compile time but at any rate at run-time.

OK? If not, there's more in the book...

Michael Kay

> --Jim
> -----Original Message-----
> From: Michael Kay [mailto:mike@xxxxxxxxxxxx] 
> Sent: Wednesday, January 19, 2005 11:14 AM
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: RE: [xsl] Comparing node for identity using union
> > 
> > This might be a good time for one of the gurus on this list 
> to briefly 
> > explain data-types in XSLT for us n00bs.
> Are you interested in the XSLT 1.0 story or the 2.0 story? 
> They are very
> different.
> Michael Kay
> http://www.saxonica.com/

Current Thread