GNOME Bugzilla – Bug 153094
Generally vague error reporting
Last modified: 2021-07-05 11:00:06 UTC
Please describe the problem: In working with xsltproc I have noticed that a lot of time is spent on understanding errors xsltproc reports, and debugging errors in the stylesheet which xsltproc didn't detect. Perhaps it's by design("xsltproc is not a validator, it's a processor"), but I've heard other processors have useful error report, and it's no doubt it would make work more productive if exact error reporting existed. Examples of unproductive error reporting: * When a key is misplaced, such as inside a template, xsltproc says "key was not compiled" even though it's invalid XSLT; it doesn't tell where, or what is wrong. * An xsl element can have a wrong attribute(such as a select attribute in a template element) and xsltproc silently accepts it. * An xsl:message is between a xsl:for-each and a xsl:sort; the error message doesn't explicitly tell what's wrong It would be very useful if xsltproc detected _any_ mistakes the user have done -- any errors in the stylesheet -- and reported what kind of mistake, and where. IMHO, good error reporting from processors such as compilers, is a sign of a user oriented thinking, and something which can be used in production environments. Cheers, Frans Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
Very first thing to do if you want "production" quality software is to use recent one ! http://xmlsoft.org/XSLT/news.html 1.0.33: Sep 12 2003 i.e. the verion you indicated is 1 year old, there have been 11 releases since then ! http://xmlsoft.org/XSLT/bugs.html indicates clearly "make sure you are using a recent version, and that the problem still shows up in those" I would appreciate if you could do this. It also indicates "Please send the command showing the error as well as the input and stylesheet (as an attachment)" So please provide the examples we will be able to use for regression testing. I'm fine being pontificated (sounds nearly like you were forced to use libxslt and try to get your revenge, if that's the case, I'm sorry but it's not our fault), but at least follow the guidelines. Anyway if you provide examples we will certainly fix problems they expose. For general validation, right this wasn't a goal, this can be added if done in a smart way which doesn't destroy performances. Daniel
Ah, sorry for the inability of taking care of even the basic preparations, and any negative tone. I'll return with up-to-date software, and exact descriptions of the error messages(if any). Cheers, Frans
Okay no worries. Doing those checks are a good idea at this point. The best place to actually catch those problems would be in preproc.c for example in xsltStylePreCompute() big switch per element. The tests needed to check the XSLT element position w.r.t. the grammar could be done there. Daniel
Ok, one small test, with reservations to that I may be wrong. The following XSLT has a template with an not allowed attribute, and inadequate of other attributes(match or name, AFAICT). <?xml version="1.0" ?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> <xsl:template INVALIDatch="/" /> </xsl:stylesheet> xsltproc silently accepts this. Cheers, Frans
Another one. Tell me if you want me to file against another product. The XSLT below is run with the following message: xsltApplyOneTemplate: key was not compiled <?xml version="1.0" ?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> <xsl:template match="/"> <xsl:key name="name" match="*" use="*@foo"/> </xsl:template> </xsl:stylesheet> xsl:key is a top level element, and that XSLT is invalid XSLT. Good behavior would be to bail out, and report on what line xsl:key was, as well as tell it must be a toplevel element. FYI, these cases are produced with: bash-2.05b$ xsltproc --version Using libxml 20616, libxslt 10112 and libexslt 810 xsltproc was compiled against libxml 20616, libxslt 10112 and libexslt 810 libxslt 10112 was compiled against libxml 20616 libexslt 810 was compiled against libxml 20616 Cheers, Frans
*** Bug 158553 has been marked as a duplicate of this bug. ***
Perhaps all elements must be looked over for tests that checks for illegal attributes, but it applies at least to the output element too. For example, this is silently accepted: <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> <xsl:output asdsa="dfoo" indent="yes" /> </xsl:stylesheet> For the import statement, the error message is a bit peculiar. For a stylesheet that looks: <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> <xsl:import asdassadasdasdsd="asdsas" /> </xsl:stylesheet> The error message is: compilation error: file test.xsl line 5 element import xsl:import : missing href attribute And to my knowledge, the import element shouldn't have a attribute named href. Perhaps it should report the invalid attribute first, since the user probably thinks he/she have entered the right attribute, but don't realize the typo.
I shall endeavour to enhance this behaviour, but please be patient (the priority must be lower than, for example, fixing a crash). Please continue to log any substantially different examples (i.e. other than attributes which don't belong, misplaced key, and misplaced message) under this bug report. For your information, the href attribute is a "required" attribute for import (see http://www.w3.org/TR/xslt#import).
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/libxslt/-/issues/ Thank you for your understanding and your help.