Re: [xsl] metrics for evaluating xsl-t?

Subject: Re: [xsl] metrics for evaluating xsl-t?
From: Tony Graham <tkg@xxxxxxxxxxxx>
Date: Wed, 23 Aug 2006 10:47:00 -0400
Robert Koberg <rob@xxxxxxxxxx> writes:
> Tony Graham wrote:
>> Since I have only vague ideas on what to measure to determine
>> complexity, I would have the complexity stylesheet output XML
>> representing the counts for the different factors being measured in
>> case the weighting for the various factors ever needs to change.  It
>> would also make it easier to write one complexity stylesheet that
>> would be used to compute multiple complexity metrics, just as the
>> cyclomatic complexity page refers to multiple, complementary metrics.
> Wouldn't this all be dependent on the source XML? In other words, if you are
> dealing with one set of XML (data oriented) and I am dealing with another
> (document oriented) and X is dealing with yet another (tree/nested), the XSL
> would be widely different. And for good reasons. Would you want to compare
> those?

As Michael Kay quite rightly said, it all depends on what you are
measuring it for.

If you were surveying stylesheet complexity, just to see what the
general experience is, I would also expect different trends for
XML-to-XML, XML-to-(X)HTML, and XML-to-FO transformation types.

If you are contemplating a short term job doing maintenance on a
stylesheet that someone else wrote, then one consideration is how much
time you need to put it before you understand what's going on.  A
stylesheet could be needlessly complex even if the XML is simple.  A
proven metric could give you some idea of how long it would take
before you could effectively make large changes.

Running a generally accepted metric for the stylesheet, particularly
if the client can do it for themselves, could be more credible than
you sucking in your breath and saying "You're having problems with X?
I could change it, but it would cost ya..."  After all, the client has
probably already heard that line too many times from his



Current Thread