[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: the problem with include and import

Subject: Re: the problem with include and import
From: "Matt G." <matt_g_@xxxxxxxxxxx>
Date: Tue, 08 Jan 2002 03:16:45
namespace wasn t imported
From: David Carlisle <davidc@xxxxxxxxx>
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



Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.