[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
At 2002-01-06 07:51 +0000, Matt G. wrote:
I'm not sure what problems you are identifying.
You can choose to do this by namespace-qualifying your variable names, without changing the design of the language.
I think you may be mistaken.
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.
I've used namespace-qualified variable names in an imported stylesheet to ensure an importing stylesheet cannot "accidentally" declare a variable that would unintentionally override the variable used in the imported stylesheet.
I don't think losing the implementation benefits would be worth it.
........................ Ken
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Re: [xsl] the problem with include and import
Subject: Re: [xsl] the problem with include and import From: "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx> Date: Sun, 06 Jan 2002 11:06:45 -0500 |
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.
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.
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.
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.
I've used namespace-qualified variable names in an imported stylesheet to ensure an importing stylesheet cannot "accidentally" declare a variable that would unintentionally override the variable used in the imported stylesheet.
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.
........................ Ken
-- Training Blitz: 3-days XSLT/XPath, 2-days XSLFO - Feb 18-22, 2002
G. Ken Holman mailto:gkholman@xxxxxxxxxxxxxxxxxxxx Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/ Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (Fax:-0995) ISBN 0-13-065196-6 Definitive XSLT & XPath ISBN 1-894049-08-X Practical Transformation Using XSLT and XPath ISBN 1-894049-07-1 Practical Formatting Using XSLFO XSL/XML/DSSSL/SGML/OmniMark services, books(electronic, printed), articles, training(instructor-live,Internet-live,web/CD,licensed) Next public training: 2002-01-10,11,16,18,02-11,12,13,15,18,21, - 03-11,14,15,18,19,04-08,09,10,12
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] the problem with include , David Carlisle | Thread | RE: [xsl] the problem with include , Michael Kay |
Re: [xsl] Re: . in for, Dimitre Novatchev | Date | Re: [xsl] Re: . in for, Jeni Tennison |
Month |