SAXON 9 / ALTOVA (2008 SP1) and coding style

[RolfK]

Dear Experts,

I have a behaviour I can not understand. May be I even not understand
the typing in a variable declaration correctly.
Please have a look to the following code snipets which behave
differently for ALTOVA and SAXON 9. The key funktion is not important
here.

<xsl:variable name="vReferenceTemp" select="key('kShell','Generic')/
xs:float(@Temperature)" as="xs:float"/>
(The as="xs:float" may be superflous here)

My first attempt was
<xsl:variable name="vReferenceTemp" select="key('kShell','Generic')/
@Temperature" as="xs:float"/>

This runs perfectly with SAXON 9 but lead to an error message
complaining the type when the variable is used later in case of
ALTOVA.

So, what is the right coding style , or what is the difference ?

<xsl:variable name="vReferenceTemp" select="key('kShell','Generic')/
xs:float(@Temperature)" />

or

<xsl:variable name="vReferenceTemp" select="key('kShell','Generic')/
@Temperature" as="xs:float"/>


Any hint is welcome

Rolf

 

[Martin Honnen]

Dear Experts,

I have a behaviour I can not understand. May be I even not understand
the typing in a variable declaration correctly.
Please have a look to the following code snipets which behave
differently for ALTOVA and SAXON 9. The key funktion is not important
here.

<xsl:variable name="vReferenceTemp" select="key('kShell','Generic')/
xs:float(@Temperature)" as="xs:float"/>
(The as="xs:float" may be superflous here)

Are you sure that you don't want
as="xs:float*"
here? key() gives you a sequence of nodes and doing
/xs:float(@Temperature) gives you a sequence of float values.

My first attempt was
<xsl:variable name="vReferenceTemp" select="key('kShell','Generic')/
@Temperature" as="xs:float"/>

This runs perfectly with SAXON 9 but lead to an error message
complaining the type when the variable is used later in case of
ALTOVA.

Well how exactly do you use the variable later, what is the exact error
message?

 

[Dimitre Novatchev]

Probably Altova implements a more pessimistic static checking than Saxon. If
it is not possible to guarantee at compile time that all @Temperature values
are convertible to xs:float, pessimistic static type-checking may raise an
error while a more optimistic and flexible type checking will not.

Of course there will be always a run-time error if the conversion is not
possible. Therefore, Altova's early error is not of great value at all, if
one can circumvent this by changing "@Temperature" to
"xs:float(@Temperature)", because this is just a promise/good-wish from the
programmer and a run-time error will definitely happen, if this good wish
has been unrealistic.

Also, the more "typed" expression that Altova accepts is actually more
unreadable than the more "untyped" one.

No information, necessary for understanding and readability, is lost in the
"more untyped" xsl:variable definition. because it still has its type
declared as xs:float.

Despite the fact that in this case Altova's type checking is apparently more
pessimistic. they do not strictly follow this pessimistic discipline, as
Altova does not complain that the cardinality of the expression may be
different (more than one) than 1. Such inconsistency is quite annoying,
because the programmer has only to guess what is allowed and what is not
allowed.

Cheers,
Dimitre Novatchev