GNOME Bugzilla – Bug 631803
evaluating unknown system property aborts transformation
Last modified: 2012-08-16 07:59:23 UTC
Evaluating the system property "msxsl:version" (in a debugging XSLT) aborts the transformation with a runtime error: xmlXPathCompiledEval: evaluation failed runtime error: file xslt-test.xslt line 137 element value-of XPath evaluation returned no result. Version information: xmlXPathCompiledEval: evaluation failed runtime error: file xslt-test.xslt line 137 element value-of XPath evaluation returned no result. See also: https://bugs.webkit.org/show_bug.cgi?id=47453
Created attachment 172039 [details] test case
(In reply to comment #0) > Version information: > > xmlXPathCompiledEval: evaluation failed > runtime error: file xslt-test.xslt line 137 element value-of > XPath evaluation returned no result. Oops. Using libxml 20707, libxslt 10126 and libexslt 815 xsltproc was compiled against libxml 20707, libxslt 10126 and libexslt 815 libxslt 10126 was compiled against libxml 20707 libexslt 815 was compiled against libxml 20707
Yes, and I don't see why that's a bug :-) It's a program and part of the program ask for access to unknown data. The data isn't available, so erroring out is the only way to handle this in a predictable fashion. As far as I know all programs and programming environment fail when something like this arise, you can't continue with random data, the only bug I see there is that - that error might be catcheable at compilation time instead of run time - the error message could be a bit nicer, but it's due to the decoupling between libxml2 and libxslt so why is that a bug ? Daniel
(In reply to comment #3) > Yes, and I don't see why that's a bug :-) > It's a program and part of the program ask for access to unknown > data. The data isn't available, so erroring out is the only way > to handle this in a predictable fashion. Hm, no. See <http://www.w3.org/TR/xslt#misc-func>: "...Function: object system-property(string) The argument must evaluate to a string that is a QName. The QName is expanded into a name using the namespace declarations in scope for the expression. The system-property function returns an object representing the value of the system property identified by the name. If there is no such system property, the empty string should be returned...." (emphasis last sentence) From a practical point of view, vendor-defined system property would never work in cross-vendor XSLTs as there'd be no way to safely check their value (there's no "property-available" checker comparable to "function-available", after all). > As far as I know all programs and programming environment fail > when something like this arise, you can't continue with random data, > the only bug I see there is that > - that error might be catcheable at compilation time instead of run time > - the error message could be a bit nicer, but it's due to the decoupling > between libxml2 and libxslt > > so why is that a bug ? Well, libxslt is in conflict both with the spec (cited above), and not consistent with other implementations.
Hm, why is this still "unconfirmed"?
See also test case at: http://greenbytes.de/tech/tc/xslt/#ft-system-property-unknown Note that libxslt seems to do the right thing when the system property is in a known namespace (such as "xsl:foobar').
Proposed fix: https://github.com/nwellnhof/libxslt/commit/f21e6bab1303e65db0f49cee899094c804a4281a
Julian, sorry for comment 3, you were right, I was wrong ! And for the delay :-\ Nick, thanks a lot, that looks just fine, I pulled and just tweaked a minor formatting glitch before pushing :-) http://git.gnome.org/browse/libxslt/commit/?id=abb7c65980c7da450f0447dcc6a1821eef99d473 thanks a lot ! Daniel