RE: [XPath] Request XPath implementations be required to do some static type checking on the schema-element function

I've got mixed feelings about this one.

The argument for the status quo is that if a product doesn't provide this
feature, you don't have to use that product. In fact you can do your
development and debugging on a processor that does this checking, and then
confidently deploy on a processor that doesn't. We've deliberately left some
aspects of the language at implementor discretion; let the market decide.

On the other hand, adding all the type information to variable and parameter
declarations and XSLT match patterns that enables static checking is a
significant investment for users, and they want some confidence that they
will get a return on this effort without reducing their ability to switch
processors. Users would be more inclined to declare their types if they had
this guarantee.

There's a particular oddity about the typing rules for path expressions,
which is that there is no dynamic type error raised if you do
schema-element(Book)/Foo; you simply get an empty sequence back. The static
semantics handle this with the very peculiar rule that any expression other
than () that is statically void is an error. This rule is over-harsh for the
static semantics (and violates substitutability), and it leaves the dynamic
semantics with nothing other than the opportunity to raise warnings. It's
also a rare case where the static semantics are optimistic: you will get
this error for schema-element(Book)/Foo but not for Book/Foo.

We could instead have a rule, applying both to the static and dynamic
semantics, that it is a type error to use any Axis Step with a downwards
axis if the type annotation on the context node is such that no node on that
axis can satisfy the NodeTest. Adding such a rule would make it a
conformance requirement to detect the error either at compile time or at run
time. However, in the common case where no static type information is
available, detecting this dynamically might be very expensive.

I'd like to see the spec do better in terms of rules that catch misspellings
in path expressions, but it's very difficult to see how to do it. Meanwhile,
taking the selfish viewpoint, I'm comfortable achieving competitive
advantage by having a product that does it better than other conformant
implementations. 

Michael Kay


>  
> > implementations are allowed to raise these errors or warnings
> 
> Thanks Michael. I understand.  I would like the specification 
> to be changed from MAY to MUST.  That is, implementations 
> MUST raise an error or warning.
> 
> /Roger
>

Received on Thursday, 27 March 2008 23:05:10 UTC