Subject: Re: [xsl] metrics for evaluating xsl-t?|
From: "bryan rasmussen" <rasmussen.bryan@xxxxxxxxx>
Date: Wed, 23 Aug 2006 13:51:34 +0200
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.
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.
Cheers, Bryan Rasmussen
On 8/23/06, Michael Kay <mike@xxxxxxxxxxxx> wrote: > > > Wondering if anyone has given any thought to a metrics for > > evaluating > > > the complexity of a stylesheet based solution? can be XSL-T > > 2.0 only. > > > > IMHO it depends on your definition for complexity. > > I think he's looking for a definition.
Yes, part of what I am looking for is a definition. I have personal opinions, and I suppose most of us know when we consider that a stylesheet is complex or more complex than it should be.
> > I think the question was asked in terms of static complexity - number of > modules, templates, functions, and their degree of interrelatedness. >
Probably need to identify complexity in xpath to be useful, but yes, those were part of the metrics.
Things I might assume to apply:
Number of includes, imports..
Reuse, overriding of templates..
use of apply-templates vs. apply-templates select..
number of modes, number of priority
use of entitities.... ---
>I've never been sure how useful such metrics are.
Most of the time not useful. I do have one project where it might be useful to have a metric defined, as I could use it to test a large number of stylesheets, not all of them mine, and flag some for possible improvements.
At higher levels such metrics can turn into recommendations for transformation structure to particular types of tasks or for applications needing to handle large numbers of input or output formats.
An example rule at a high level can be: Put named templates into a named template xsl for import. override as needed.
Thus if one has a named template not an override of a named template in the named templates xsl flag stylesheet for checking by top level transformation maintainer - that would be you, Michael - and so forth.
complexity is probably one of the top things we want to reduce in an application, thus we need a metric to identify at least possible complexity in order to automate checking for it.
I have made some preliminary things in this direction but was hoping others had some stuff as I always feels somewhat uncomfortable making an argument without seeing what other opinions are on the matter, since what I perceive as important can on consideration turn out only to be based on personal preference.