Re: the problem with include and import

Play the video

Subject: Re: the problem with include and import
From: "Matt G." <matt_g_@xxxxxxxxxxx>
Date: Tue, 08 Jan 2002 03:16:45

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

Re: the problem with include and import, (continued)
- Matt G. - Sun, 6 Jan 2002 16:47:55 -0500 (EST)
- Matt G. - Mon, 7 Jan 2002 06:39:51 -0500 (EST)
  - David Carlisle - Mon, 7 Jan 2002 07:38:53 -0500 (EST)
- Matt G. - Mon, 7 Jan 2002 22:15:52 -0500 (EST) <=
  - David Carlisle - Tue, 8 Jan 2002 04:40:46 -0500 (EST)
    - Andrew Welch - Tue, 8 Jan 2002 05:25:04 -0500 (EST)
    - Michael Kay - Tue, 8 Jan 2002 06:53:57 -0500 (EST)
    - Andrew Welch - Tue, 8 Jan 2002 07:38:37 -0500 (EST)

<- Previous	Index	Next ->
Re: the problem with include , David Carlisle	Thread	Re: the problem with include , David Carlisle
Using xsl:key to list unique , Trem Stamp	Date	XSLT/XPath Conformance - invi, G. Ken Holman
	Month

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

RSS 2.0
Atom 0.3

XML Editor - Download a 15 Day Free Trial Now >

See What's New in Stylus Studio >

Buy Stylus Studio - XML Editor - Now >