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>).
Andrew Welch Wrote
.,..
IDEs like oXygen provide intellisense based on the associated XML in
the scenario, but I don't know of any one which will highlight
impossible XPaths given a schema.
Without picking on any IDE product specifically, general assistance
with composing 'valid' XPath expressions in a static environment is,
in my view, not what it could be. (I'll hold up my own hand here
because my own XPath product still has some way to go too - AND it
doesn't support XPath 2.0 - yet!).
This relatively poor XPath support contrasts with the extremely
sophisticated functionality XML IDE products provide elsewhere, for
example in dynamic XSLT debugging.
To me, this seems like a missed opportunity because it should be
possible to detect a significant number of error types as the
expression is being written. Also, the emphasis on detecting errors at
'runtime' in IDEs may encourage a development style that doesn't take
full advantage of the declarative nature of XSLT and XPath.
Phil Fearon
http://www.sketchpath.com
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--