Subject: RE: [xsl] Re: Is an XPath processor responsible for catching misspelled tag names when there is an associated Schema? From: "Michael Kay" <mike@xxxxxxxxxxxx> Date: Fri, 22 Feb 2008 09:11:44 -0000 |
> 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/
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] 0utput Escaping not behav, Joe Fawcett | Thread | Re: [xsl] Re: Is an XPath processor, Andrew Welch |
Re: [xsl] Re: Is an XPath processor, Colin Paul Adams | Date | Re: [xsl] Re: Is an XPath processor, Andrew Welch |
Month |