This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: the problem with include and import
- From: "Matt G." <matt_g_ at hotmail dot com>
- To: xsl-list at lists dot mulberrytech dot com
- Date: Tue, 08 Jan 2002 03:16:45
- Subject: Re: [xsl] the problem with include and import
- Reply-to: xsl-list at lists dot mulberrytech dot com
>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