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. Cheers, Abel Braaksma Exselt XSLT 3.0 streaming processor http://exselt.net
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[xsl] Schema-awareness and built-in, Max Toro maxtoroq@xx | Thread | Re: [xsl] Schema-awareness and buil, Max Toro maxtoroq@xx |
Re: [xsl] Term/Definition Lookup, Terry Badger terry_b | Date | Re: [xsl] Schema-awareness and buil, Max Toro maxtoroq@xx |
Month |