After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 153094 - Generally vague error reporting
Generally vague error reporting
Status: RESOLVED OBSOLETE
Product: libxslt
Classification: Platform
Component: general
1.0.33
Other All
: Normal normal
: ---
Assigned To: Daniel Veillard
libxml QA maintainers
: 158553 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-09-19 19:19 UTC by Frans Englich
Modified: 2021-07-05 11:00 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Frans Englich 2004-09-19 19:19:37 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:
Comment 1 Daniel Veillard 2004-09-19 21:33:13 UTC
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
Comment 2 Frans Englich 2004-09-19 21:39:40 UTC
 
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 
 
 
Comment 3 Daniel Veillard 2004-09-19 21:56:03 UTC
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 
Comment 4 Frans Englich 2004-11-11 20:45:17 UTC
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
Comment 5 Frans Englich 2004-11-11 21:10:40 UTC
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

Comment 6 Daniel Veillard 2004-11-17 14:19:49 UTC
*** Bug 158553 has been marked as a duplicate of this bug. ***
Comment 7 Frans Englich 2004-12-04 00:30:26 UTC
 
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. 
 
 
 
Comment 8 William M. Brack 2004-12-04 03:41:07 UTC
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).
Comment 9 GNOME Infrastructure Team 2021-07-05 11:00:06 UTC
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.