Thank you for your explanation. So if ever any other XSLT2
implementation will see the light of day, one could wait for
that implementation to behave differently again, because of
the maturity of type-checking?! I just expected type-checking
at run-time, that's why I had no clue about what was going on.
The working group made an explicit decision to allow processors to choose
how much type checking to do at compile time, and how much to defer until
run-time.
For simple type errors like format-date(143), or 3*"London", I think people
would get quite irritated with a processor that didn't report this as a
compile-time error. And generally, the more type checking is done
statically, the less dependent you are on having 100% test coverage to find
all your coding errors. One the XQuery side, the WG set out initially to try
and define interoperable static typing rules in the formal semantics: but
they soon gave up, and recognized that processors could try to be smarter
(or less smart) than the rules in the spec. On the XSLT side, we never even
made the attempt to define the static typing rules.
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--