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

["James Fuller" <james.fuller.2007@xxxxxxxxx>]

On Feb 3, 2008 6:59 PM, Michael Kay <mike@xxxxxxxxxxxx> wrote:
> > Wanted to share a little project called debugxslt
>
> I'm wondering about the requirements. Are you trying to catch a subset of

what I expect from any kind of lint checker;

  * reporting on constructions that are well formed and valid xslt,
but not 'what we want'
  * enforcing best practice
  * validation (use xslt schematron schema)

> the static errors that an XSLT processor would report, or a superset? Or is

I guess I would like a superset,

be great also to be able to augment XSLT and processor specific error messages;

for example consider the following XSLT snippet;

XSLT processor:<xsl:value-of select="system-property(xsl:vendor)"/> /
<xsl:value-of select="system-property(xsl:version)"/> / <xsl:value-of
select="system-property(xsl:vendor-url)"/>

when processed in SAXON, it rightly returns an error;

'Fatal Error! java.lang.IllegalArgumentException: key can't be empty
Cause: java.lang.IllegalArgumentException: key can't be empty'

the error is quite valid but the message is a bit arcane ... perhaps
over time a better error message would say something about quotes
missing .... I am not picking on SAXON specifically, all XSLT
processors errors are trying their best to be informative to end users
... would be useful in a lint checker and debugger to be able to
annotate more information to help give some 'hints' if things have
gone wrong ... this is especially helpful in the situation where the
error thrown, is masking some more fundamental error.

I am digressing though as none of this would (i do not think so) be
using any of schematrons capabilities.

> the main aim to produce better diagnostics? Or to run faster? I don't really

yes, better diagnostics ... the list of XSLT constructions, I had in
initial email, are common 'gotchas' which a developer can spend lots
of time debugging on.

> get it.

> >   <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>
>
> The first rule will be caught using the schema for XSLT, or using an XSLT
> processor. The second rule is stricter than the rule in the spec, you are
> imposing rules of good practice that go beyond what's in the language

this ruleset is just illustrative; an afternoons output .... the first
rule illustrates schematron in its role as validator ;) I didn't
include XSLT schematron schema just yet, wanted to see if other folks
have gathered up any interesting xslt 'lint' over the years.

> specification. Which is fine if that's what you're setting out to do.
>
> >   <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>
>
> Here you're checking for a small subset of the errors that can occur in
> defining a match pattern, and frankly, I don't see the point. You're also
> catching things that aren't errors at all, like match="a[contains(.,'[')]",

unbalanced brackets are not errors but commonly not what one wants in
@select, @match, @test attributes.

> while missing errors like match="a[f(c])".

yup, don't like this either ... I can see lots of lint rules like this
and with XSLT 2.0 (or EXLST) we at a minimum have regex to help us
identify.

> (And what's the "-1" doing on both sides of the comparison?)

hehe, didn't even notice that, and it makes me chuckle ... desiring -1
as a result when comparing counts() and there was nothing matched,was
a habit picked up in some other (very long dead) programming language,
my fingers seem to remember though ... its been many years since I did
that though.

> Also, you're applying this incorrectly to the match attribute of literal
> result elements, extension elements, and top-level data elements.

thx for pointing that out, I have tinkered with schematron in the
past, but still a novice with it;

also I am getting some warnings using the newer xslt 2.0
implementation which I will confirm before posting to schematron list.

cheers, Jim Fuller