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?

These are not exactly the choices at present. What we have is:

   A. An early static error, which in cases may be totally false.

This is witnessed with pessimisting type checking. The "correction" is to
add dynamic-cast functions (one-ore-more(), zero-or-more() and
exactly-one()) with the total net effect that what is proclaimed to be
static type checking or even pessimistic type checking in reality becomes
dynamic type checking. The benefits of static type checking are gone in
this case. 

   B. A runtime error.

In the cases discussed above it does not come later than if using static
type checking + dynamic casts to save it from breaking.

   C. No error but some implicit behaviour that the user may not even
      expect or understand?

This will happen in cases when in order to save static type checking the
type definition is so much relaxed as to make it completely useless --
e.g. see how min(), max() and avg() are defined in the F&O latest draft.

This is the worst possible solution.

> 
> 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).

I wonder how you arrived at this conclusion. I did strongly react against
C. as expressed in my comments in the thread on "[F&O] 15.3 Aggregate
Functions" in this list -- see for example
http://lists.w3.org/Archives/Public/public-qt-comments/2003Nov/0283.html

What I think is the best decision is to have an early static error where
possible and 100% sure, excluding any possibility for false alarms. In the
cases when this is not possible the type checking system should gracefully
delay its decision till run time. Ideally, this should be implicit and
should not require that the user specifies explicitly dynamic casts.

So, if we have this definition:

 fn:max($arg as xdt:anyAtomicType+) as xdt:anyAtomicType

and we have the expression:

  max( () )

then the system will report the error immediately at compile time.

If the expression is:

  max( myElementName )

where myElementName may or may not evaluate to the empty sequence,

then the decision if there is an error or not will be done at run time and
an error will be raised only if myElementName evaluates to the empty
sequence.

This achieves the best from the two worlds -- the first error is reported
immediately at compile time, while in the second case there is no false
alarm and no need for the user to write:

  max( one-or-more(myElementName) )


Thank you,

Dimitre Novatchev


> 
> 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
> > 
> > 
> > 
> 
> 


__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

Received on Tuesday, 2 December 2003 01:04:16 UTC