Re: [XQuery] static typing of node comparisons

> It may be better to either use exactly-one() or zero-or-one(),
> use [1], use a for iterator,

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.


> or define is and <<,>> using existential quantification.

That might work for "is" but in practice with the current type
definitions, all user defined functions are going to have to do
something similar.  If you type your function as requiring node() it is
virtually unusable as so few expressions can be statically typed as
returning a node.

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 Monday, 1 December 2003 06:20:06 UTC