This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: the problem with include and import


>From: "Michael Kay" <michael.h.kay@ntlworld.com>
>Reply-To: xsl-list@lists.mulberrytech.com
>To: <xsl-list@lists.mulberrytech.com>
>Subject: RE: [xsl] the problem with include and import
>Date: Sun, 6 Jan 2002 19:27:27 -0000
>
>>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).
>
>This is why variable names are QNames. It makes sense if you define
>a module intended to be reusable, e.g. a module for trigonometry,
>to define a namespace name such as http://trig.com/trig.xsl and to
>name all templates, functions, and global variables with this
>namespace name.

I see this (now), but I can't think of a good reason why a stylesheet should 
determine the namespace in which the template and variable names it defines 
exist, other than to keep these *private*.  IMO, you want the *importing* 
stylesheet to determine what namespace the external module's names are in.

As I said, previously, I think this could still be added as the default 
namespace of the imported module.


Am I missing something?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]