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: http://www.oreillynet.com/xml/blog/2006/05/metrics_for_xml_projects_5_str_1.html 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. Regards, Tony.