Subject: Re: [xsl] metrics for evaluating xsl-t?|
From: Andrew Franz <afranz0@xxxxxxxxxxxxxxxx>
Date: Thu, 24 Aug 2006 06:29:13 +1000
"bryan rasmussen" <rasmussen.bryan@xxxxxxxxx> writes:<snip/>
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.