[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] XSLT Lint 0.1

---

---

On 02/14/2011 03:48 PM, Michael Kay wrote:

While this is laudable, a refactoring like this one:

<!-- old -->
<xsl:variable name="varName">
<xsl:value-of select="xpath"/>
</xsl:variable>
<!-- new -->
<xsl:variable name="varName" select"xpath"/>

isn't safe without first doing a lot of semantic analysis. I think the
preconditions for this to be correct are something like:

"all uses of $varName are dependent only its string value"

Perhaps is there some API in Saxon that would tell if XPath is likely to produce single-value or sequence? I mean:
concat('a', //a, 'b') will definitely produce single value
//a/concat('a', ., 'b') is likely to produce sequence

The tool is implemented in XSLT+regexp, simple regexp like "^concat\(.*\)$" might work, but generic solution would be better

It looks to me as if your tool is trying to do refactorings based purely
on local textual pattern matching. That might give good results 95% of
the time, but 95% seems inadequate to me.

That's the point -- tool is not modifying original code, but instead writes new code to a totally different folder. Afterwards user launches file comparison tool, performs file compare and chooses only those line changes he likes.

I do not think 100% refactoring tool is possible. For example, if we take Java static analysis tools, they have all the required information, but sometimes they give false positives, even such great tools as FindBugs. Every change FindBugs is suggesting should be carefully reviewed manually in one-by-one mode, not all changes are ok. Same applies for XSLT lint -- use file compare tool to display line-by-line differences, and tons of mouse clicks to copy changed lines.

---