Because the value of an expression used in an inputValueCalc element isn't needed until runtime, the implementation does not currently even examine the expression until runtime. However, this misses an opportunity to capture and give things like "unknown variable name" errors as Schema Definition Errors at compile time.

So, the IVC code paths need to compile the expression before parsing begins.

In addition, I noticed that the code used to determine if an expression is constant just assumes that any error at all means the expression is not constant. The way it works is this. We know an expression is constant if it doesn't need any context-node (that's the infoset) to resolve paths into the data, and if it doesn't need any variables to be bound. The way the test works is it actually attempts to evaluate the expression in a context where there is no context node, and the variable map is empty so that any variable will be unbound. If this evaluation fails (throws an expression evaluation exception), it is then assumed the expression is non-constant. If we get a value back, then that value is the constant value.

The problem: a syntax error, or illegal namespace prefix, or various other expression problems will cause an expression exception, so that what is clearly a compile-time error in the schema will simply be deemed to be 'non-constant'.

We need to separate out exceptions that are due to the context node, and due to the use of an unbound variable, and those indicate non-constant. Other exceptions indicate actually problems with the expression.