[XQuery] SAG-XQ-001 Static vs dynamic typing

SAG-XQ-001 Static vs dynamic typing

1. We find that that the use of the terms "static" and "dynamic" typing is
confusing to users. Every serious implementation of XQuery (like every
serious implementation of XSLT 1.0) is going to do some static type
inferencing. The distinguishing characteristic of the "static typing option"
is not that these systems do static type inferencing, but that they do it
"pessimistically", that is, they reject queries that might otherwise produce
dynamic type errors. We suggest that the term "strict static typing" might
be more appropriate. (We are not proposing to produce products that offer
this optional feature, because we do not think it offers benefits to users).

2. The working draft of 2 May 2003 contained the statement "If an
implementation can determine by static analysis that an expression will
necessarily raise a dynamic error (for example, because it attempts to
construct a decimal value from a constant string that is not in the lexical
space of xs:decimal), the implementation is allowed to report this error
during the analysis phase (as well as during the evaluation phase)."

This statement has disappeared in the current draft, and we believe that it
needs to be reinstated in some form. Certainly, systems that do not do
strict static typing should be allowed to reject constructs at compile time
if static type inferencing shows that they can never succeed.

3. An unusual feature of the XQuery type system is that there is a value,
(), which is an instance of many different types. This means that an
expression such as string-join(1 to $n, ",") would succeed, in the case
where (1 to $n) is empty; in all other cases it would fail. We think the
rules should be phrased so that a system that does not do strict static
typing is allowed to reject this expression at analysis time. Possible
wording would be: "A processor, even if it does not perform strict static
typing, may report a type error during the analysis phase if it can
establish that every possible non-empty value of the expression would fail
to match the required type for the expression".

Michael Kay
for Software AG

Received on Thursday, 27 November 2003 06:58:15 UTC