"bryan rasmussen" <rasmussen(_dot_)bryan(_at_)gmail(_dot_)com> 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.
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--