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

Re: [xsl] Schema-awareness and built-in types

Subject: Re: [xsl] Schema-awareness and built-in types
From: "Abel Braaksma (Exselt) abel@xxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 12 Jun 2014 14:17:36 -0000

On 11-6-2014 17:45, Max Toro maxtoroq@xxxxxxxxx wrote:
> The following doesn't work in an XSLT processor with basic conformance:
> <xsl:element name="a" type="xs:integer">5</xsl:element>

using [xsl:]type or [xsl:]validation tell the processor to validate
against the type defined in a schema. That the type you specify is one
of the core types does not change the fact that a non-schema-aware
processor is not aware of a schema, not even a schema with the core
types. More strictly speaking, the specification states that such a
processor MUST signal an error:

"[ERR XTSE1660] A non-schema-aware processor must signal a static error
if the stylesheet includes an [xsl:]type attribute, or an
[xsl:]validation or [xsl:]default-validation attribute with a value
other than strip, preserve, or lax."

Even if such a non-schema-aware processor were able to do a certain
level of simple validation, it is not allowed to do so.

> even though you can create variables using the built-in types:
> <xsl:variable name="a" select="5" as="xs:integer"/>

The as-attribute tells the processor to convert the variable into the
supplied type and signal an error if it cannot do such a conversion.
This is not the same as validation. A variable does not have a
type-attribute and can therefore not be validated.

> or use the constructor functions:
> <xsl:variable name="a" select="xs:integer('5')"/>

It would not be possible to create typed integers or dates at all if we
hadn't allowed constructor functions. But the constructor functions are
limited to the built in schema types, whereas a schema-aware processor
allows constructor functions on other types as well.

> What's the reason for this restriction? Why can't I use built-in types
> to annotate new nodes?

The reason, the way I see it, is that a non-schema-aware processor is
not aware of the type annotations (in fact, every element is annotated
with xs:untyped and every attribute with xs:untypedAtomic). This makes
sense, because it cannot use the type annotations (it cannot validate
them). But not being able to convert a built-in type to another type is
a very basic requirement. So conversion is possible, albeit only with
built-in types, but any other type manipulation is not.

Of course, one could argue that a non-schema-aware processor still has
to do validation of built-in types. At the time I was not a member of
the working groups, so I cannot say much about _why_ this limitation was
made the way it is now, but at the end of the day, they will have needed
to draw a line in the sand, defining what schema-awareness entails and
what non-schema-awareness entails.

With a little bit of work, however, you can do limited schema-awareness
with a non-schema-aware processor, by using the conversion methods that
are available, and XPath operators like castable as and instance of, as
long as you stick to the built-in types. Within XSLT 3.0 you can extend
that with try/catch and raise your own errors if this (limited)
validation fails.


Abel Braaksma
Exselt XSLT 3.0 streaming processor

Current Thread