RE: [XQuery] static typing of node comparisons

Note that we talk about the rule that if you get a static inference of *
or + and you expect a ? or 1 that you get a static error. I don't see
this as a hard issue. Maybe some of the type inference rules are
problematic, but not this.

And note again, if you operate without the conservative static typing,
you do not have the issue. However, there are cases, where the
conservative static typing provides benefits that outweigh the cost of
writing explicit casts both in performance and cleaner, more explicit
semantics.

Best regards
Michael

> -----Original Message-----
> From: David Carlisle [mailto:davidc@nag.co.uk]
> Sent: Monday, December 01, 2003 3:48 PM
> To: Michael Rys
> Cc: dnovatchev@yahoo.com; public-qt-comments@w3.org
> Subject: 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 20:14:47 UTC