tag:blogger.com,1999:blog-5568788882760066320.post5318169846902863886..comments2018-08-27T15:40:06.058+02:00Comments on lichtblau's blog: Macros for XSLTDavid Lichteblauhttp://www.blogger.com/profile/05088343424853670990noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-5568788882760066320.post-7310742166887871622007-07-30T10:50:00.000+02:002007-07-30T10:50:00.000+02:00That's quite cool. However, I see a workflow probl...That's quite cool. However, I see a workflow problem creeping behind the corner: In Lisp (hey, even in C), macro processing in built-in. It's not in XSLT. This implies that in CL you can simply throw your macro definitions into the code where you need them, the CL system will see it and do the right thing. And in C, cpp will be called anyway during the build process and you're fine. But in XSLT, you have different files and have to do the macro processing by hand. Which in turn has consequences whenever more than one programmer is involved. Heck, it's likely that even with one programmer and three months later that somebody will work *only* with the result of the macro expansion. This is extremely likely to happen if you're using a built-in XSLT library and none of the stand-alone XSLT processors.<BR/><BR/>In CL, there is a saying that one should use macros only when necessary. Given the above, I would conclude that for XSLT, the advice should probably read to avoid macros at all cost.<BR/><BR/>Of course, none of this is your fault and I'm very grateful you pointed out the idea and provided the code. Now, if only the W3C would recommend this idea ... :-) <BR/><BR/>PS: Thanks also for the link to Novatchevs FXSL library. It doesn't suffer from the problem as one simply imports XSLT templates (which is standard in XSLT in contrast to preprocessing of stylesheets), I think.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5568788882760066320.post-55453444471011432902007-07-28T23:41:00.000+02:002007-07-28T23:41:00.000+02:00coolcoolAnonymousnoreply@blogger.com