SAXON 9 / ALTOVA (2008 SP1) and coding style

Discussion in 'XML' started by RolfK, Dec 16, 2008.

  1. RolfK

    RolfK Guest

    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

    <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

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

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


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

    Any hint is welcome

    RolfK, Dec 16, 2008
    1. Advertisements

  2. Are you sure that you don't want
    here? key() gives you a sequence of nodes and doing
    /xs:float(@Temperature) gives you a sequence of float values.
    Well how exactly do you use the variable later, what is the exact error
    Martin Honnen, Dec 17, 2008
    1. Advertisements

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

    Dimitre Novatchev
    Dimitre Novatchev, Dec 18, 2008
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.