Cart
|
[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: the problem with include and import
 From: David Carlisle <davidc@xxxxxxxxx> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx Date: Mon, 7 Jan 2002 09:17:40 GMT I don't, however it was only the last couple messages in which I mentioned anything about templates (I had been focusing too much on variables). The whole point of the import mechanism is that one can import an existing stylesheet and then over-ride existing named constructs (templates, variables, ..) so the "problem" you describe isn't really a problem it is the main point if xsl:import. The "whole point"? I think there are other reasons to import a stylesheet than just to override locally-defined named templates and variables (such as overriding matches, if I'm not mistaken). Anyhow, what I was proposing was an *option* to supply a namespace for the imported templates. Maybe it makes more sense on "include". Maybe it's not the primary goal of the WG, but what I really want is a language that will scale. Foremost among the issues I've encountered that mitigate scalability of systems is a lack of modularity. As it exists, XSLT allows modular design and implementation, however this seems strongly dependent on conventions used to implement *both* sides of an interface between stylesheet modules. What I'd like to see are enhancements that protect the user, by default, where it doesn't affect the flexibility of the language, as well as features which allow the user to better protect h(er|im)self from unsafe practices used in external modules. Matt Gruenke
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
