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 09:03:13 -0400
"bryan rasmussen" <rasmussen.bryan@xxxxxxxxx> writes:
> The other thing is determining the complexity of the transformation
> task, pertinent to the individual transformation and its place within
> a transformation framework.
> With that kind of metric one can then determine the amount of time for
> writing transform etc.

I got onto the metric idea from the other end: determining what it
would take to understand and maintain an existing stylesheet if I got
work where there are stylesheets already in use.

> of course, as noted, this is different than analysing the complexity
> of an actual transform.
> don't think there's anything like that. Although Sean McGrath had a
> blog post once about the true cost of XML, cost includes the number of
> namespaces to be understood etc.
> I think we all have a builtin metric for saying how complex we feel a
> particular transform likely will be.

I'd like a simple measure of how complex a particular transform was.

For the record, I got started on the XSLT metric idea after reading
about Rick Jelliffe's XML complexity metric:

The future conference paper that I'd like to see (and present) is the
one with lots of manager-friendly graphs relating schema complexity
and XSLT complexity from a survey of real projects.  If that existed,
it would be easier to explain to your manager why a new stylesheet for
a new, complex schema could take longer than a week to write.



Current Thread