January 19, 2005

Michael Kay discusses XSLT 2.0 Types on xsl-list

I had to take a few hours off of the new site design and focus on another project. I was just sending off a response in regards to this project when a pointer to this post from Michael Kay arrived on my radar screen. Can I first suggest if you are really interested in reasearching XSLT 2.0 from the inside-out that the best thing for anyone to do is to spend the $75 US Dollars, cheaper if you buy it online, and purchase Dr. Kays XSLT 2.0 and XPath 2.0 titles. You can not find a better reference that goes any further into explaining XSLT (both 1.0/2.0 titles) and XPath (1.0 is covered in XSLT 1.0 book, 2.0 is its own seperate book) than through the very editor of the 2.0 specification, Dr. Kay. Go ahead, buy 'em, I'll wait here for you....

Ok, cool... While you are waiting for your package from Amazon to arrive heres something to tide you over :) Earlier today on XSL-List in response to a question regarding XSLT 2.0 Types Dr. Michael Kay writes:

>
> 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
as="element(purchase-order)".

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
name.

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
http://www.saxonica.com/