RE: [XQuery] static typing of node comparisons

The first semantics is not that a logical choice if you look at
expressions such as 

$x = $y

and 

$x = $y+0

And is certainly not the expected behaviour by non-XPath 1.0 users (and
even there will be many that do not know this particular behaviour,
based on my experience).

The casting (which btw can in this case also be done by [1]) is not such
a big burden to the user and it makes the semantics explicit which in my
opinion is good.

We can certainly argue about whether we need all three functions below
or if a pick() (taking one from the sequence) or the() function (same as
exactly-one()), would be sufficient.

The design of the type system at the moment is that you either use the
dynamic typing rules (that work as you seem to like it) and which can
have some tests done statically, or that you perform pessimistic static
typing.

I think you will probably be a customer for the dynamic typing
implementations and not the static typing implementations.

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

> -----Original Message-----
> From: Dimitre Novatchev [mailto:dnovatchev@yahoo.com]
> Sent: Monday, December 01, 2003 1:22 PM
> To: Michael Rys; David Carlisle; public-qt-comments@w3.org
> Subject: RE: [XQuery] static typing of node comparisons
> 
> 
> --- Michael Rys <mrys@microsoft.com> wrote:
> > 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.
> >
> 
> It is logical in this case to use the first item of the sequence for
the
> operation and to ignore the rest.
> 
> The operation expects a single argument. It gets a sequence of more
than
> one argument. Therefore it has the single argument needed -- and this
is
> the first item of the sequence.
> 
> Why operate on the first item? Because this will work in every case --
> even in the case when the sequence consists of just one element.
> 
> This semantics may seem "strange". However, it has been proven to be
> useful and effective in practice when it is well documented and known.
If
> many thousands of programmers are using XPath 1.0 without problems
then
> why should this semantics be changed?
> 
> If the change was needed to simplify and correct something, then it
> obviously didn't achieve these goals -- we are commenting on the
anomalies
> of the "pessimistic static typing", which require either relaxing the
type
> so much as to render it useless, or using dynamic-cast clutches such
as
> zero-or-one(), one-or-more() and exactly-one().
> 
> If this (otherwise well-intended) attempt to simplify and correct the
> XPath 1.0 semantics is failing so obviously, then the conclusion is to
> follow the semantics of XPath 1.0, which, although seeming "strange"
at a
> surface glance, has passed the reality tests by serving well its
users.
> 
> Using this semantics it is possible to have type-checking that does
not
> exhibits the anomalies discussed, does not need any clutches and is
really
> useful.
> 
> 
> Dimitre Novatchev
> 
> 
> 
> __________________________________
> Do you Yahoo!?
> Free Pop-Up Blocker - Get it now
> http://companion.yahoo.com/

Received on Monday, 1 December 2003 17:39:00 UTC