[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: Sun, 06 Jan 2002 21:18:33
problem with include
At 2002-01-06 07:51 +0000, Matt G. wrote:
It occurred to me, while I was considering the issues relating to
stylesheet library modularity with respect to dynamic scoping, that global parameters and variables already present a problem (if I'm
not mistaken).

I'm not sure what problems you are identifying.

Namespace collisions. The way global variables behave can allow silent bugs that may be difficult to find. For example, you start using a variable unintentionally of the same name as a global variable, in a template, but forget to declare it as a parameter. It has sensible values (after all, if they share the same name, chances are they probably have the same type), but not always what you want. Especially if it's used in an intermediate stage of processing, you get incorrect results, but it's not at all clear where the problem is.

Global variables always present such risks (which is why programmers have a tradition of using a special naming conventions for them), but that's not exactly the problem with which I'm concerned. What I'm concerned about is that you may have no control over a stylesheet library you're using, and thus can't ensure (such as if it's precompiled) that such a convention is being used.

Furthermore, variables declared in included or imported stylesheets could allow bugs to silently creep into your code. That's not a thought that makes me very comfortable. Then, there's the problem of two separate stylesheet libraries, each of which declares a global variable of the same name.

In my opinion, they ought to have been scoped to the file in which they're specified.

You can choose to do this by namespace-qualifying your variable names, without changing the design of the language.

But you may not always have a choice! (see above) While this strategy can work, if you're in control of all your stylesheets, I contend that there's a simple, natural way to extend the language to enforce modularity. What's wrong with adding a "with-param" to the content model for include and import? If dynamic scoping is added to the language (as discussed), this would be a very light-weight alternative to global variables being truly global, and it would fulfill all the existing capabilities in a more explicit manner.

I'm concerned that (assuming I'm not mistaken), if these issues aren't addressed, it may be very difficult for stylesheet
libraries of any significant complexity to be developed and used,

I think you may be mistaken.

Heh, I was referring to my knowledge about the behavior of the relevant XSLT language constructs, upon which my conclusion was drawn. It goes without saying that my conclusion may be incorrect or irrelevant.

In fact, I didn't actually know that variable names could be in an XML namespace. However, I still don't think that completely solves the problem.

I've found the ability to declare a default value for a variable in a given module and then import that module overriding the initial
value for that variable to be *very* powerful.

You could still do this, it'd just be a bit more verbose. I'm thinking a stylesheet module would provide a template for each variable it wanted to export. You'd call those templates, when setting your variables, rather than just getting the variables it defines, when you include it.

Furthermore, this would also provide more static optimization
opportunities to XSLT processors supporting some sort of evaluate()
function which supports variable references.

I don't think losing the implementation benefits would be worth it.

I don't see that you'd really be losing any flexibility. I see it as forcing you do be explicit about what you want to export to other stylesheet modules, and them to be explicit about what they want to imported.

Hmmm... since the same problem exists with named templates, maybe the real solution is to be able to supply a new namespace for each imported or included stylesheet. I actually think this would make a lot more sense than the current ability to supply a the namespace of a variable or template at the point of definition. In fact, I don't see a case where you'd even want to supply a namespace at the point of definition, if you could provide it on include/import. Perhaps a way to fit this into the language would be to treat it as a default namespace for the external module.

Anyhow, I appreciate the thoughtful reply.

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

Current Thread


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.
First Name
Last Name
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.