RE: [XQuery] static typing of node comparisons

I personally think that having a conservative type checking will catch
more errors and will allow more performing implementations. By making
some of the castings explicit, the user also will better understand the
cost involved in the execution and get the semantics he/she really wants
(and not just the one we came up with for convenience reasons). 

I also wonder what you think will hurt a user most:

A. An early static error when writing a query?
B. A late runtime error when executing a query?
C. No error but some implicit behaviour that the user may not even
expect or understand?

My money is on A hurting the least in the end. Your bet seems to be on
B, and Dimitre's seems to be on C (which I consider the worst).

Best regards
Michael (speaking for himself and not the WG)

> -----Original Message-----
> From: David Carlisle [mailto:davidc@nag.co.uk]
> Sent: Monday, December 01, 2003 1:08 PM
> To: Michael Rys
> Cc: dnovatchev@yahoo.com; public-qt-comments@w3.org
> Subject: RE: [XQuery] static typing of node comparisons
> 
> 
> > since that would move type checking from the static typing phase
into
> > the dynamic phase.
> 
> That is true of course, but the solution chosen moves the burden of
type
> checking, inserting explicit casts and exactly-one() all over the
place,
> to the user rather than the system. No one (including the authors of
the
> spec, as shown by this thread:-) is ever going to get this right first
> time, so writing xquery is going to be a matter of trial and error
> trying to passify the type checker. This completely nullifies any
> potential benefits of a static type checker in catching programmer
> errors early.  I say Xquery as I would expect (hope) that few xpath
> implementations would use this system. It would be hard to persuade
> anyone that an xpath2 using the static type feature had any benefits
> over xpath1. Some extra useful functions (regexp, mainly) a lot of
less
> useful functions and a type system that makes using the system without
> without getting errors on the first few attempts at each expression
> virtually impossible.
> 
> David
> 
> 
>

Received on Monday, 1 December 2003 17:43:51 UTC