RE: comment on Xpath 2.0 - no strong typing!!

Michael Kay wrote [Thu, 3 Oct 2002 13:08:07 +0200]
> The term "strong typing" means different things to different people.
> There are some type rules in XPath 1.0, for example you cannot
> supply a number as an argument to the count() function or as an
> operand of the "/" operator.
>

At the risk of being pedantic, I'd just like to point out that "strongly
typed" has a well-defined meaning, and any other use of the term is just
a corruption of the language.  See, for example,
http://whatis.techtarget.com/definition/0,289893,sid9_gci213058,00.html
We can quibble over minor details (as always), but the core meaning
holds.

The confusion over XSLT/XPath stems largely from the fact that these
languages are, as you well know, only "half-way" strongly-typed.  With a
handful of exceptions (external parameters, external script functions),
every expression in XPath and XSLT 1.0 has a type that is known at
compile-time.  Granted, these types are fairly weak (number, node,
etc.), although some compile-time analysis can improve that somewhat
(integer, double, element, attribute, ...), but nevertheless, almost all
expressions in an XSLT/XPath are strongly typed.

I've heard the XQuery WG comment publicly several times now that XSLT is
weakly-typed and not optimizable, and I think you are doing yourselves a
disservice by resorting to flawed argumentation.  Numerous XSLT
implementations can and have successfully applied both strong-typing
rules and non-trivial optimizations (even though the standard did little
to lay a solid foundation for either).

Furthermore, eliminating implicit type conversions does not make a
language more strongly-typed -- it just makes it more rigid (which can
be a positive aspect).  For example, raising an error whenever a
sequence has more than one member instead of just handling the case with
some reasonable semantic (even if that's something silly like first
semantics in XPath 1.0), is not a requirement to claim the language is
strongly-typed.  In some cases raising an error may help to discover a
user error at compile-time; in other cases, it only makes the language
more verbose and less usable.


Best wishes,

Michael Brundage
xquery@attbi.com

Received on Monday, 9 December 2002 10:53:50 UTC