RE: [XQuery] static typing of node comparisons

My fear is that A will hurt most as the number of places where the
typing rules produce error messages that will be inexplicable to anyone
who hasn't spent months pouring over the darkest regions of the specs
is just so great that the language verges on the unusable if the
specified static typing is turned on (and in some cases even if it is
not, see for example Jeni's paper at Extreme discussing some problems that
affect even users of xslt without static type checking (which thankfully
is not really supported in xslt). Thus the effect of A is no program at
all  (or the program written in a different language, xslt1, omnimark,
perl,...)

the "first node" semantics of xpath1 sometimes (well, often) catch out
the beginner but the rule is simple to explain and simple to
remember. the same can hardly be said of the static typing rules from
the FS document.

At this "last call" stage for xpath/xslt 1 there were several more or
less complete implementations available. It is noticable that there is
as far as I know currently only one widely available xpath2
implementattation (saxon) and that does not implement the static typing
rules. I hope the WG are aware that XPath2 is viewed at best with
suspicion and commonly with horror in large parts of the existing Xpath
user base (and xpath1 implementors). The baroque nature of the typing
system, and the arbitrary and unexpected extra use of explicit casting
that it forces on the end user must play a large part in the negtive
perception that Xpath is facing.

David

Received on Monday, 1 December 2003 18:49:20 UTC