RE: Re: Is an XPath processor responsible for catching

> So, as it appears from previous answers, for a number of 
> reasons, the XPath processor can not take responsibility for 
> catching misspellings.

> But surely something should? (Also misspellings can still 
> frequently be valid in the schema due to different contexts 
> but similar element names such as <field> and <filed> or 
> <book> and <books>).

Yes, it's disappointing that the language semantics are such that on many
occasions, a misspelt name will simply result in retrieving nothing. This is
a consequence of the fact that many users expect to be able to run queries
on untyped data with no schema and therefore no means of distinguishing
correct paths from incorrect ones.

As I mentioned in my previous reply, you can do a lot better if you take
care to define the types of your variables and parameters, and to use
constructs like match="schema-element(book)" rather than simply
match="book", to make it clear that you only want to match books that
conform to the schema definition.

I have had it in mind for quite some time to experiment with some stronger
checking than this: to see what happens if you assume that match="book"
means match="schema-element(book)", and produce warnings as if that had been
written. I refer to this concept as "assumed validity". The main difficulty
with implementing this is that Saxon currently uses the same type
inferencing rules for diagnostics and for optimization; to do this well, you
would need to keep a "known type" used when generating code, and a "best
guess type" used for diagnostic warnings. (Actually, the guessed type can
also be useful for optimization - you can sometimes generate fast path code
for the expected case, and a slower path for use if your compile-time
guesses turn out to be wrong. Saxon occasionally does this for cardinality
guessing, specifically for expressions that can usually be expected to
produce a singleton.)

Michael Kay
http://www.saxonica.com/