W3C home > Mailing lists > Public > public-qt-comments@w3.org > February 2004

ORA-XQ-092-B: definition of static typing is too rigorous to be useful

From: Stephen Buxton <Stephen.Buxton@oracle.com>
Date: 16 Feb 04 11:43:56
Message-Id: <200402161943.i1GJhuG00937@rgmgw5.us.oracle.com>
To: public-qt-comments@w3.org
Cc:

SECTION 2.6.2: static typing feature

Section 3.7.3.1 "Computed element constructors" gives an 
interesting example of a way to construct an element with the 
same name as a given element, but with a different content.
The note following the example says that the example is not
portable because it will not work under the Static Typing
Feature.  To me, this example calls into question the utility
of the feature.  The note gives a workaround, using the function
fn:exactly-one, and the F&O has additional functions which will
overcome certain other static typing issues.  The conclusion I
draw is that anyone interested in portable programming will
be required to use these functions as guards to explicitly
disable the static typing feature, in case the application is
ported to such an implementation.  The purpose of the guard
functions is to give the application precisely the behavior it
would have had if the static typing feature were not supported.

I am wondering if the problem is in an overly fastidious 
notion of what static typing should do for the user.
To me, a function invocation fct(arg) whose sole parameter is 
declared to be item() or item()+ with an argument arg whose static 
type is item()? or item()* does not look like a static type error, 
because it is possible that the command will succeed at run-time.
I suggest that the static typing feature should raise type 
errors when the static type of an actual argument or operand
has empty intersection with the required type in that position.
In such a case it is a certainty that there would be a run-time
error, and therefore a user benefit to provide early detection of
such errors.  I can see this as a user benefit even if the 
code is unreachable, because it probably reveals a logic error on
the user's part.  But to raise static errors for situations 
that might run successfully on certain inputs seems like a 
disservice to the user.  

- Steve B.
Received on Monday, 16 February 2004 14:44:00 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:17 UTC