Re: Schema-awareness and built-in types

I don't see a technical limitation, other than forcing the programmer
to use schemas to do any kind strongly-typed programming with nodes.
A node has a typed value only because an XSD schema document says so?
That's sad.
A basic processor knows everything about these built-in types, it
shouldn't have any problems annotating new nodes to use them.
--
Max Toro


On Thu, Jun 12, 2014 at 10:18 AM, Abel Braaksma (Exselt)
abel@xxxxxxxxxx <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> 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