This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: the problem with include and import


>From: David Carlisle <davidc@nag.co.uk>
>Date: Mon, 7 Jan 2002 12:36:51 GMT
>
>ues matches (and keys) I meant the whole point of xsl:import is to >allow 
>the importing stylesheet to override the imported one.
>
>The behaviour of variable definitions is just a consequence of that,
>so I fail to see why it is seen as a problem rather than a feature.

Oh, I wasn't 100% sure that you couldn't set the imported module to a higher 
precedence than the importing one, but I guess not.  That still doesn't 
change my position, however, as it wasn't central to my argument.

Just to clarify, I'm not talking about matches, here, just named templates 
and variables.  Also, allow me to observe that problems can masquerade as 
features, and vice versa.  It all depends on context (see below).


> > Anyhow, what I was proposing was an *option* to supply a
> > namespace for the imported templates.
>
>I don't see how that would work. Everywhere in xpath/xslt a
>namespace is just an integral part of a name not some dynamic
>construct that can be changed on the fly.

I don't know to what degree parsers support QNames as attribute values, so 
in that regard, what I was describing may require more work for the 
processor implementers.  But nothing I'm describing is changing "on the 
fly".  In my opinion, named constructs not declared to be in any XML 
namespace, in an imported stylesheet, should have separate bindings in the 
imported one than they do, internally (or for stylesheets the imported 
module imports).  In this way, accidental use or overriding of imported 
constructs can be avoided, if not desired.

Overriding is a nice idea, and can be very convenient, for simple cases, but 
it doesn't scale very well (a lesson learned the hard way, by many OO 
programmers).  With that in mind, I say that overriding should be possible, 
but there should also be a mechanism for avoiding it.


>Changing a qname from namespace a to namespace B
>is no different from changing its local name.

I wasn't talking about *changing* its name.  Just adding other bindings for 
importing stylesheets.


Anyhow, there appears to be little interest in this thread.  I guess 
robustness & scalability aren't high priorities for the WG or other users on 
the list.  Alternatively, perhaps I'm just making a very poor case for the 
vulnerabilities and limitations of the include/import mechanism, due to the 
decision to constrain name scoping, via XML namespaces, to be done only on a 
per-stylesheet basis, rather than allowing namespaces per-stylesheet 
instance.

Maybe I'll try to construct some examples.


Matt Gruenke


_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]