"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.