W3C home > Mailing lists > Public > public-qt-comments@w3.org > November 2006

[Bug 3818] Static typing of $input-context1/works[1]/employee[1]/empnum[1]

From: <bugzilla@wiggum.w3.org>
Date: Fri, 03 Nov 2006 09:04:16 +0000
To: public-qt-comments@w3.org
Message-Id: <E1GfuyG-0001VD-Kx@wiggum.w3.org>


------- Comment #8 from mike@saxonica.com  2006-11-03 09:04 -------
"In doing so, the system is capable of _not_ rejecting some queries.  However,
the current type rules are preventing use of this information.  So there exist
situations in which a user, in trying to add extra type information, is
actually forcing to the system to throw away more specific type information and
_causing_ a query to be rejected."

If a user is calling a function that expects an element(employee) and says
"treat as element(employee)" then they are effectively saying "please do
dynamic type checking on this" (probably because they are bewildered by the
static type error that they got before they added the "treat as"). This case
should never give a static error. 

On the other hand, if they call a function that expects element(employee) and
they say "treat as node()", then a static error seems perfectly reasonable. The
rule is designed for the former case, which is much more likely to occur in

I'm afraid I don't have time, however, for debate on the details of pessimistic
static typing. I think the whole edifice is pretty unusable, which is why most
implementors are ignoring it (even those who claim to support static typing are
using their own custom inference rules). In fact, I think that users of static
typing systems will be obliged to litter their code with "treat as"
expressions, forcing the system to behave exactly like one with dynamic typing.
All your comments pointing out perfectly reasonable expressions that fail under
static typing serve merely to reinforce my views on this.

That's a personal comment of course.
Received on Friday, 3 November 2006 09:04:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:16 UTC