Tell me why this is a bad design.

Basically I have an application that I am designing.  I need to be able to 
give my users the ability to customize some of the functionality by editing 
or changing scripted areas and provide base functionality in compiled code 
that cannot be changed.

In the past this was accomplished with a vb application which referenced the 
 scripting ocx which loaded a series of vb script files.  The script files 
were able to interact with the VB application and were very flexible when 
customizations were needed.  Customizations were moved into compiled code as 
it was appropriate.

In the release that I am designing I have the following goals, 
•	I want to use C# to design the compiled piece
•	I want to use xslt to house the scripted code which would allow the script 
to be written in any of the .NET languages.  I will be focusing on jscript or 
javascript but will also be able to use C#, VB.Net and others if I want to in 
the scripting blocks.
•	I want to expose the compiled extension objects to the script blocks so 
that compiled base functionality could be used in the script blocks


"Oleg Tkachenko [MVP]" wrote:

> STurquette wrote:
> 
> > Given the following transformation, is it possible to call the UtilityMethod 
> > that is coded under the Group2 namespace from a function within the Group1 
> > name space without rewriting the UtilityMethod in the Group1 namespace?
> 
> XSLT spec doesn't define it. Basically it's considered a poor design to 
> rely on extension functions and relying on communication between 
> extension function from different namespace is even worse. Why do you 
> need it?
> 
> -- 
> Oleg Tkachenko [XML MVP]
> http://blog.tkachenko.com
>