[
Lists Home |
Date Index |
Thread Index
]
A more interesting case is
avg(input()//part/partnumber)
where the path is a typo for //part/partprice.
In this case, you could have part numbers of the form dddddd.dd[.dddd] and
the query would work in absence of types using default conversion to numbers
(producing wrong values given the author's intent), until one of the long
partnumbers (which might be rare) was encountered. The query would be
rejected if the partnumber were typed as a string. Runtime failure is
really not a sufficient replacement for static typechecking when it is
available and fits the nature of the application.
Nonetheless, I agree that it should be possible and easy to use XPath and
XQuery without type information, and that the type systems should not impose
a significant performance penalty when not used. I could stand it if the
type system required significant extra work for implementors (say less than
2x of the cost without type system, roughly) and encouraged even more extra
work (in revision releases, perhaps) in producing optimizations when the
types were used, assuming that delivery time of specs and implementations
were not horribly extended. What's more important is what works for users.
Jeff
----- Original Message -----
From: "Simon St.Laurent" <simonstl@simonstl.com>
To: "Jonathan Robie" <jonathan.robie@datadirect-technologies.com>
Cc: <xml-dev@lists.xml.org>
Sent: Tuesday, May 07, 2002 11:04 AM
Subject: Re: [xml-dev] XPath 1.5? (was RE: [xml-dev] typing and markup)
> On Tue, 2002-05-07 at 12:54, Jonathan Robie wrote:
...
> >
> > I would like the following query to fail:
> >
> > avg( input()//person/name )
> >
> > I would like it to fail without forcing me to execute the query. That's
> > what we call static typing. This query is simply wrong, and a query
> > processor can know that.
>
> You're welcome to do that for systems you build. I'm content to have it
> fail at runtime, which is perfectly acceptable in systems where
> developers do regular testing. The identifier "name" in the context
> "person" is usually a tipoff that there shouldn't be a number in there.
>
> Distinguishing which strings can be converted to numbers is not very
> difficult. Dates are much more difficult, but I don't think anyone is
> actually that fond of XML Schema dates and times.
|
