[xsl] Re: The Perils of Sudden Type-Safety in XPath 2.0

["Dimitre Novatchev" <dnovatchev@xxxxxxxxx>]

"Jeni Tennison" <jeni@xxxxxxxxxxxxxxxx> wrote in message
news:157364526351.20030219170233@xxxxxxxxxxxxxxxxxxx

>   <xsl:variable name="danger">
>     <xsl:value-of select="@risk * @severity" />
>   </xsl:variable>
>   <xsl:value-of select="string-pad('!', $danger)" />
>
> This latter works because the $danger variable holds the document node
> of a tree that contains the value of @risk * @severity. The typed
> value of the document node is the value 7 of the type
> xdt:untypedAtomic [*]. Since the type is xdt:untypedAtomic, the value
> is cast automatically to the required type of xs:integer when the
> variable is used.

[snip]

> [*] I mistakenly talked about the type xdt:anyAtomicType in an earlier
> mail when I meant xdt:untypedAtomic.

This is just one more concrete confirmation of the fact that XSLT 2.0 is not
going to be anything close to XSLT.

When even Jeni has apparent difficulties, when the explanation why something
works requires such specialised knowledge, then the result is clear. This
leads to such artificial and not logical tricks as the above...

In a previous message Mike Kay defended the new type checking as necessary
for (type I guess) polymorphism.

While this is generally true, there would be functions (probably not just a
few)  that will not have polymorphic behaviour -- e.g. the string-pad()
function.
Why should type checking be required in such cases?

One of the critiques about XSLT 1.0 is that it's too verbose. From what I
see about XSLT 2.0, transformations written in it may well have to be twice
as verbose as their XSLT 1.0 counterpart.

It seems to me that this tendency will adversely affect programmer
productivity -- I hope someone could prove the opposite...

Probably when we 're trying to define what constitutes a successful and
popular programming language, it would be haelpful to look at:

http://www.paulgraham.com/popular.html

One of the factors there is "brevity"... but probably it's already late to
read this article?



=====
Cheers,

Dimitre Novatchev.
http://fxsl.sourceforge.net/ -- the home of FXSL




 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list