Vincent Lefevre wrote: > On 2008-04-15 13:56:46 +0200, Stefan Behnel wrote: >> Vincent Lefevre wrote: >>> On 2008-04-15 12:33:42 +0200, Stefan Behnel wrote: >>>> What could be wrong in telling the user that he/she made a mistake >>>> instead of hiding the problem that was discovered during XSLT >>>> evaluation and that lead to an incorrect result? >>> How can a XSLT processor read in the user's mind? >> Well, it stops processing, > > On your example, it doesn't. It seems that xsltproc or libxslt > regards "ival" as "/ival", i.e. with the context /, but I don't > know if this is allowed or not.
Ok, I was a bit confused here and actually tried different things. When I try a really invalid value in xsltproc, it /does/ signal the error: # xsltproc --param value "<ival>" test.xslt test.xml XPath error : Invalid expression <ival> ^ runtime error Evaluating user parameter value failed Reading the source of xsltproc, I found out that the transform state "STOPPED" does not, as you might expect, signal a terminated transformation in general, but a failed transformation that stopped without a fatal error, so it is just seriously badly named and misleading. A doc update on xsltTransformState might help here. The above example does not seem to be a fatal error for libxslt, so it returns the broken result document and sets the transform state to "STOPPED" at the end. To me, any error that stops short and leads to an incomplete result looks very much like a fatal error, but maybe that's just me. So now that I figured out that I can treat "STOPPED" as an error just like "ERROR" (except that I have to xmlFreeDoc() the result myself), I know how to work around this problem. Thanks to all who helped out. Stefan _______________________________________________ xslt mailing list, project page http://xmlsoft.org/XSLT/ [email protected] http://mail.gnome.org/mailman/listinfo/xslt
