Wendell,
If you kept it in its own box, completely separate from other
transformation logic, it would be fine. The nightmare would be if you tried
to combine this with ordinary transformation logic, which typically would
perform a mapping of source elements to result elements, do grouping,
conditional generated text, etc. Both things happening in a single
stylesheet would be a lot to try to keep under control and a pain to
maintain. Also, writing output to text locks you into a particular
processing model (can't chain the transform as easily, can't use it in
display engines that don't support the 'text' output method, and so forth).
Writing a transform to do such reformatting on arbitrary input, and having
it be the final step of a two- (or multi-) step process, is more thinkable.
Three or four templates would do everything you would need. Is there any
reason you can't do it that way? (Or maybe you're saying that's what you
want to do.)
It does make more sense to do it in the way you're suggesting. I appreciate
the modularization advantages. We actually do already have a 2 step
transform, and my hesitation to have yet another stage is only in terms of
efficiency. 2 steps is ostensibly faster than 3. Is there a lot of
overhead in invoking the transform process multiple times? say I wanted to
do it 10, 20 or 60 times?
Abie
_________________________________________________________________
Get a FREE computer virus scan online from McAfee.
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list