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.

It is symptomatic of the fact the static typing will cause many spurious
errors, many users will _not_ immediately think of adding explicit casts
or [1] to correct this. And these are just the simple half-line examples
that fitted in the spec (and the spec authors still got wrong). It's hard
to know (since it seems no Xpath implementor has provided an Xpath
implentation with static typing that can be trialled) just how bad this
will be when inflicted on real users with real sized expressions. My gut
reaction (after answering literally thousands of Xpath queries on
xsl-list) is that it is going to be very bad indeed (If there are in
fact any Xpath implementations that support this feature)

  And note again, if you operate without the conservative static typing,
  you do not have the issue.

This argument is simply not true, the fact that the dynamic behaviour
has to be compatible with the currently specified static typing has
affected the entire design of the language.

Also many of us do not work in closed environments. We distribute code
that is intended to run on any (all) systems, by unknown users.
Anyone who tries this in the future is going to be swamped with "bug"
reports from end users who are trying to run code on a system using this
static typing.

The language is littered with small kludges to avoid problems with the
typing system: all the URI based functions use strings not anyuri
(presumably because the lack of implict casting makes anyuri incredibly
inconvenient to use) substring and friends take double rather than
integer arguments (presumably for the same reason, although perhaps
compatibility with xpath1 was also an issue there) backward
compatibility can't be the reason for subsequence taking double though.

The WG have taken years to specify the functions in F&O and they are
still, at each draft, tinkering with the signatures to try to get
functions that have a usable behaviour given a typical input file and
path expression. In the wild, end users won't have this luxury, they
will quickly learn that they need to give any function they define the
most general type possible in order to avoid spurious type errors in use.
In other words they will have to learn to avoid to the static typing
completely, which is a real shame as static typing (given a typing
system that is well tuned to the data)  _does_ have many benefits.

David

________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________

Received on Tuesday, 2 December 2003 05:14:20 UTC