xsl-list
[Top] [All Lists]

[xsl] [ann: debugxslt v.0.1]: a (very) experimental xslt lint checker using schematron

2008-02-03 06:42:28
Hello All,

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 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 it becomes a bit more
useful for this kind of thing, and I wanted to spend a sunday
afternoon gathering my thoughts ... since it is now sunny and the
puppy needs a walk, 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 schema and use in your own schematron processing setup.

Currently It has a very limited ruleset, in sch/xslt-std.sch, written
in straight schematron schema

<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="*[(_at_)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="*[(_at_)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="*[(_at_)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)

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(_at_)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
in XSLT2, e.g. working with 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
author a hint of what common problem is occuring.

In any event, would welcome any comments .... 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 SVRL report xslt template ?

--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--