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

Having the user write such runtime checks (such as exactly-one()) is
making the cost of runtime cardinality checks obvious. I think that
there are two camps that can use static typing.

The conservative camp will implement static typing since they want to
avoid an implicit runtime error in these cases.

The progressive camp will implement dynamic typing but use static typing
to find the cases that will always fail.

Our current rule allows both, and I think this is the right thing.

Best regards
Michael

> -----Original Message-----
> From: public-qt-comments-request@w3.org [mailto:public-qt-comments-
> request@w3.org] On Behalf Of Stephen Buxton
> Sent: Monday, February 16, 2004 3:44 AM
> To: public-qt-comments@w3.org
> Subject: ORA-XQ-092-B: definition of static typing is too rigorous to
be
> useful
> 
> 
> 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 22:20:35 UTC