RE: [XQuery] static typing of node comparisons

Actually the spec writer did not get it wrong. They decided to write the
queries to work with dynamic semantics and not necessarily with the
static semantics. The reason is that the static semantics is defined in
the formal semantics spec. 

The anyURI vs string issue I actually agree with you. I think that they
should be mutually weakly typed. However, this is not because of the
conservative static typing rules but because of the strong typing rules
people wanted to preserve between anyURI and string. The functions that
take double are taking double mainly because of XPath 1.0
backwards-compatibility.

Best regards
Michael

> -----Original Message-----
> From: David Carlisle [mailto:davidc@nag.co.uk]
> Sent: Tuesday, December 02, 2003 2:14 AM
> To: Michael Rys
> Cc: dnovatchev@yahoo.com; public-qt-comments@w3.org
> Subject: 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 13:25:55 UTC