Actually this was labeled as a compile-time error message in my case.
But no doubt it can occur at run-time as well...
Actually, when I looked more closely, I found that this is a case of an
error that's defined as a dynamic error in the spec, but is being detected
statically (which is allowed, under some fairly byzantine rules in the XPath
spec). And the reason for the relative vagueness of the message wasn't in
this case loss of information between compile-time and run-time, but rather
than the condition was being detected in a superclass covering a wide
variety of different kinds of expression, and the message wasn't being
customized to the particular kind of expression. Which is now fixed.
That would be nice... the root (excuse the term) of the
problem here is that you're trying to communicate to the
programmer an error that is caused by a condition that is
camouflaged. The programmer is trying to access the context
node when there is no context node, but often it is far from
clear (to us mortals) that the stylesheet as written would
need to access the context node!
Yes indeed. Design of error messages often has to find the right compromise,
given that there are readers who understand the language and its terminology
very precisely and others who don't. There are messages in Saxon that are
conceptual howlers (like "attempting to write an attribute when there is no
open start tag") where I may have bent a little too far towards
communicating with the ignorant, and others where I am no doubt too
technical for the majority.
Michael Kay
http://www.saxonica.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>
--~--