Re: [xsl] the problem with include and import

["Matt G." <matt_g_ at hotmail dot com>]

>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,
>>successfully.
>
>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