[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

[ann: debugxslt v.0.1]: a very experimental xslt lint checker using late

• From: "James Fuller" <james.fuller.2007@g...>
• To: "xml-dev@l..." <xml-dev@l...>
• Date: Sun, 3 Feb 2008 17:48:27 +0100

Hello All,

[apologies for the cross post ]

Wanted to share a little project called debugxslt, which uses
Schematron assertions and report statements to catch out all those
little errors that well formedness (or even validation) does not catch
(or even masks).

my initial attempts at such a utility (some years ago) took the form
of a perl analyzer that would scan an xslt file; I never released
because its part of a larger thing, which in turn is very ugly perl
(though over a pint I would argue it was beautiful due to its use of
perl's recdescent parsers and regex).

now that schematron has exslt, xslt2 bindings (regex and lots of other
goodness)... I think its worth expirementing;  I wanted to spend a
sunday afternoon gathering my thoughts ..., I guess I am done.

debugxslt can be found here;

   http://code.google.com/p/debugxslt/

u will need to have Ant installed, download the Schematron Ant task
and have an available XSLT 2.0 processor, pref SAXON

  or

you could just take the schematron schema and use in your own
schematron processing setup (find it under sch/xslt-std.sch or just
copy the example below)

Currently It has a very limited ruleset, in sch/xslt-std.sch, written
in straight schematron schema ... these are meant to illustrate the
technique.

<schema xmlns="http://purl.oclc.org/dsdl/schematron"
               queryBinding='xslt2'>

 <title>XSLT Lint</title>

 <ns prefix="xsl" uri="http://www.w3.org/1999/XSL/Transform"/>

 <pattern>
    <rule context="xsl:stylesheet">
       <assert test="count(@version) = 1">All XSLT files should have a
single version attribute.</assert>
       <assert test="@version = '1.0' or @version='2.0'">There are only
XSLT version 1.0 or 2.0.</assert>
    </rule>
 </pattern>


 <pattern>
    <rule context="*[@match]">
        <report test="@match=''">empty match attribute</report>
        <assert test="count(tokenize(@match,'\[')) - 1 =
count(tokenize(@match,'\]')) - 1">unbalanced brackets</assert>
    </rule>
 </pattern>

 <pattern>
    <rule context="*[@select]">
        <report test="@select=''">empty select attribute</report>
        <report test="contains(@select,'concat')">ensure 1st arguement to
concat() function is an element or quoted text</report>

        <assert test="count(tokenize(@select,'\[')) - 1 =
count(tokenize(@select,'\]')) - 1">unbalanced brackets</assert>
    </rule>
 </pattern>

 <pattern>
    <rule context="*[@test]">
        <report test="@test=''">empty test attribute</report>
        <assert test="count(tokenize(@test,'\[')) - 1 =
count(tokenize(@test,'\]')) - 1">unbalanced brackets</assert>
    </rule>
 </pattern>

 <pattern>
    <rule context="*">
        <report test="xsl:parem">incorrect spelling of xsl:param</report>
    </rule>
 </pattern>

 <pattern>
    <rule context="xsl:call-template">
        <report test="xsl:with-param">there is no xsl:with-param on the
call-template</report>
    </rule>
 </pattern>

</schema>

which looks for;

   * checks for version attribute on xsl:stylesheet
   * unbalanced brackets in @test, @select, @match attributes
   * for empty values in the same attributes
   * some examples for checking typos (xsl:parem versus xsl:param)

there is no a lot of magic happening here ... we could also include a
more classic validation of XSLT (1 and 2) but I wanted to focus on
'lint' type problems that are hard to debug even if file is well
formed and valid. If free time presents itself, I may add a full
fledged schematron schema for XSLT.

I have a few more ideas for 'lint rules' to define;

   * Unused defined modes
   * Undefined modes
   * Undefined named templates
   * unused defined named templates
   * Templates that use name= where match= was probably intended
   * xsl:call-template elements that contain anything other than
xsl:with-param
   * Variable/parameter references that are not defined at the point of use
   * Forgot to add @ to attribute, common with prefixed attributes
   * Misunderstanding of addressing attributes or missing brackets
with attribute ex. <xsl:variable name="testvar" select="test@result"/>

here are some more difficult rules I could imagine would be helpful to report on

   * Duplicate match patterns
   * Same name different caps when addressing element
   * Same name different caps with attributes
   * Same name different caps with param/var

Lastly, there are a class of rules which I guess would not be possible
using schematron, as we would have to be able to analyze non-well
formed xml;

   * added ending angle bracket in middle of xsl:stylesheet element
   * Missing quote in select statement

another area I would find useful is the ability to annotate existing
error messages ... I find some errors 'mask' other errors and would
like to 'add' to a vendor or xslt own error message to help give an
authors hints ... when an error is either masking some deeper error or
pointers on where to look for a quick fix.

All comments welcome.... if interested in contributing rules or you
have your own ideas then give me a shout and I will give you
subversion access.

cheers, Jim Fuller

ps: does anyone have a good schematron SVRL report xslt templates ?