RE: [XQuery] static typing of node comparisons

While I understand David's sentiment, we need to understand the dynamic
semantics first if I expect a singleton and I get a sequence passed that
may be longer. 

History:
XPath 1.0 took the somewhat unfortunate decision to always take the
first item of the sequence.

We had the following choices:

1. We follow XPath 1.0. Many deemed this to be unacceptable due to the
often surprising semantics.

2. If a singleton is expected, we pass in a sequence of length greater
1, we perform a runtime check and error. This is a dynamic type check
and while dynamic type checking works this way today, it is a big
performance burden on systems implementing pessimistic static typing,
since that would move type checking from the static typing phase into
the dynamic phase. 

Note, that this performance overhead was one of the reasons why many of
my developers embraced the pessimistic static typing for now.

3. Define an implicit iteration if a singleton is expected but a
sequence is passed. While this has lots of appeal at first sight, it
starts to get complicated when we have expressions with more than one
argument. What should

(1,2,3) * (1, 2, 4)

return?

Should it be a Cartesian product: (1, 2, 4, 2, 4, 8, 3, 6, 12)
Or posititional (a la APL): (1, 4, 12)

We investigated these (and some other) options in depth in the WG and
finally decided to be pessimistic in the first version of the static
typing rules to avoid the runtime checks.

Best regards
Michael
 
> -----Original Message-----
> From: public-qt-comments-request@w3.org [mailto:public-qt-comments-
> request@w3.org] On Behalf Of Dimitre Novatchev
> Sent: Monday, December 01, 2003 5:24 AM
> To: David Carlisle; public-qt-comments@w3.org
> Subject: Re: [XQuery] static typing of node comparisons
> 
> 
> > I am usually in favour of static typing, but in a language like
Standard
> > ML, the type system is closely matched to the values and operations
in
> > the language, and type errors almost always reflect real errors (ie
run
> > time errors or incorrect results would have occurred without the
static
> > check).
> >
> > However the existence of exactly-one() appears to be an admission
that
> > the type system (or at least the type inference) in use here is
really a
> > terrible match to the underlying data and operations and I fear that
> > with the current definitions a system using the static typing as
> > specified in the FS is basically unusable, the use of the static
type
> > system will generate far more errors than it ever detects. Requiring
the
> > user to have to code special functions to work round deficiencies in
the
> > static typing is a usability disaster.
> >
> > It is probably infeasible to reliably detect whether expressions
match
> > node() rather than node()* as a static check as the cardinality of
the
> > result sequence depends on too many run time factors (eg with the
> exampbe
> > //book[isbn="1558604820"] here, unless isbn is of type ID you
haven't
> > really a hope of statically telling that this returns a single node)
> >
> > In Xquery an item is the same as a sequence of one item, and it
would
> > probably make sense to not try to distinguish these at the static
typing
> > level and not try to statically distinguish any sequence based on
its
> > cardinality (including cardinality of one).
> >
> > Obviously if node() and node()* were the same static type the
> > type system is in some sense weaker, but I think in practice the
result
> > would be that the system was far more usable with far fewer spurious
> > errors, and no requirment for fn:exactly-one() and friends.
> 
> I completely agree with David and strongly support his proposal to
change
> the rules for static type checking. He summarizes very precisely the
> current type-checking rules and the anomalies that result from them.
> Changing the type checking rules as proposed will benefit everyone.
> 
> The only remark is that instead of:
> 
> > Obviously if node() and node()* were the same static type
> 
> David probably meant:
> 
>  Obviously if node() and node()+ were the same static type
> 
> that is, to treat "exactly one" and "one or more" the same.
> 
> 
> Dimitre Novatchev.
> 
> 
> 
> 
> __________________________________
> Do you Yahoo!?
> Free Pop-Up Blocker - Get it now
> http://companion.yahoo.com/
>

Received on Monday, 1 December 2003 13:38:41 UTC