[xquery-talk] static typing of XQuery?

Frans Englich frans.englich at telia.com
Thu Sep 21 12:20:12 PDT 2006

On Wednesday 20 September 2006 17:30, Per Bothner wrote:
> How much interest is there in the "static typing" feature?

I have a hard time getting the point of it.

An implementation using the static typing feature and one that does not have 
the same chances for optimizing queries, except for when the query is not 
pessimistic-typing safe. In that case, one of the implementations generates 
runtime checks, while the other forces the user to explicitly insert the 
runtime checks. The only difference is that the latter annoys the user.

I wonder whether people implement pessimistic static typing by the 
book(because it's so annoying). The testing task force receives quite 
different reports in this area on the test suite, suggesting people approach 
this differently.

If the point is to help performance in XQuery, is this feature really the 
right way to go? Someone asserted that "most" XQuery products are glue to 
existing SQL products, and then it would perhaps be better to adapt XQuery to 
more easily translate into SQL queries[1]. Or nuke an axis or two.

For me, pessimistic typing checking raises concern because it's barely 
interoperable. Many implements custom inferences which potentially removes 
pessimistic typing errors while others do not(because it's optional and 
random), leading to queries that raise errors on some implementations. Some.

Considering this wealth of how people implement static typing, I would rather 
allow people to infer whatever they like(of course), but disallow the 
pessimistic reporting. Or perhaps only on cardinality, just that would make a 
big difference.

> As the SVN version of Qexo now passes more and more of the
> testsuite, I'm considering whether to tackle static typing.
> Qexo has the advantage that it much of the *framework* for
> static typing (it is after all a true compiler), but of
> course static typing is still a large job.  (Because of this,
> I'm unlikely to prioritize static typing soon without some kind of
> sponsorship. Please let me know if you know of a possible source
> of such sponsorship.)

Something I can recommend as implementor is to study Formal Semantics 
regardless of if you're going to implement (pessimistic) static typing. FS 
documents AST rewrites and different ways to consider expressions, which is 
quite useful when designing an implementation. I wish I had read the FS 
completely before starting implementing, although many of the simplifications 
come naturally.



1. For example, from my brief reading on Data Direct's product, it hits severe 
performance impacts on specific functions/expressions that has no SQL 

More information about the talk mailing list