RE: [ann: debugxslt v.0.1]: a (very) experimental xslt
> Wanted to share a little project called debugxslt I'm wondering about the requirements. Are you trying to catch a subset of the static errors that an XSLT processor would report, or a superset? Or is the main aim to produce better diagnostics? Or to run faster? I don't really 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 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(.,'[')]", while missing errors like match="a[f(c])". (And what's the "-1" doing on both sides of the comparison?) Also, you're applying this incorrectly to the match attribute of literal result elements, extension elements, and top-level data elements. Michael Kay http://www.saxonica.com/
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