Re: [ann: debugxslt v.0.1]: a (very) experimental xslt
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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format