Re: [xslt] Why is an invalid stylesheet parameter value not an error?



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]