Re: [xsl] the problem with include and import

["Matt G." <matt_g_@xxxxxxxxxxx>]

> From: David Carlisle <davidc@xxxxxxxxx>
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Date: Mon, 7 Jan 2002 09:17:40 GMT
>
> Why do you think the problem of scope for variable names is any
> different from the scope of (say) named templates.

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


_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com


XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list