On Sun, September 4, 2011 1:38 pm, G. Ken Holman wrote:
At 2011-09-04 09:59 +0000, Alex Muir wrote:
Something I'm just wondering for the sake of learning more...
Had XSLT only defined an xsl:include in the spec and did not define an
xsl:import such that I assume it would force the authors to use
template priorities to establish precedence.
Or get used to turning off the warning and relying on the stylesheet using
the last matching template rule.
Plus, the original specification would have
needed the equivalent of the XSLT 2.0
<xsl:next-match/> in order to allow the creation
of the onion-skin overriding stylesheet. Though
even with that the inability to override globals
would be sadly missed and cripple important functionality.
Or, since we're postulating alternative realities, global variables could
have been defined to have the same scoping rules as local variables.
Or we'd use a lot more tunnel parameters and so avoid relying on global
variables.
Would XSLT...
1. Be lot less powerful such that you could not implement something in
an xsl:import-less XSLT?
You mean like XQuery?
I'll cite again the ability to tweak the
behaviour of a read-only stylesheet. There is
The way to tweak a read-only stylesheet would then require a reliance on
the XSLT processor picking the last matching template rule (and more
attention paid to matching the @priority value of any template that you
are overriding).
You'd probably also expect a lot more use of initial modes and initial
templates and more tunnel parameters.
the scenario I mentioned earlier of creating the
"editor's rendition" stylesheet by exploiting the
"user's rendition" stylesheet with overriding behaviours.
Also, imagine it is the 11th hour of a project, a
stylesheet has been through some kind of quality
assurance, and the boss comes up with a
last-minute change. The well-defined semantics
of <xsl:import> means that the onion-skin
overriding stylesheet can redefine global
declarations used by the imported stylesheet, and
do so without creating declaration
collisions. The new combined system works as
desired and you haven't touched the base
stylesheets that have already gone through tests.
Not that you'd want to go into production without running tests yet again.
...
You can't do this in XQuery because "global"
declarations are only global to the module and
the including modules, but not to any other modules.
You can't do this in XQuery because it is imperative and not declarative.
I suggest that it's a design decision that isn't directly related to the
imperative-declarative divide.
Perl, for example, lets you override global variables.
2. Be much more difficult to program certain things or perhaps just
less convenient?
Rather than "more easy or more difficult" how
about "more safely and more conveniently"?
Declarative solutions come up with the same
results as imperative solutions, but you have far
more flexibility adapting and leveraging a
declarative solution than you do an imperative
solution. If programs never needed maintenance,
You could say much the same thing about object-oriented languages (and
many people do) without their necessarily being declarative.
then this discussion would be less
important. Though the powerful XSLT features are
not only exploited when maintaining a stylesheet
... they are also very useful when developing a stylesheet.
One of the odd things about XSLT isn't the way that you override a global
variable in an imported module but the fact that you can do it to any
top-level variable in any module.
Edsger Dijkstra noted [1] that, with hierarchical decomposition, we have
to wrap our minds around things that range in relative size from 1 to
10^9. Most computer languages strive for some sort of information hiding
to reduce this complexity, but so far in XSLT it's all laid bare for us.
About the best that you can do so far with modules is put your variable
and function names in a namespace that's unique to that module so you can
avoid accidental overrides [3].
3 Be something else....
It would be more imperative and less
declarative. The declarative nature of XSLT
allows all of the global constructs to be
overridden by simply declaring them in a module
with higher precedence (more importance).
It's pretty much dynamic scoping [2] with the proviso that you can't
override global variables within the one module (though I have no idea
whether anyone ever muttered the term "dynamic scoping" during the design
of XSLT 1.0).
Dynamic scoping isn't all that common, but it's used by Emacs-Lisp and it
was originally all you could do in Perl.
Even the "last matching template wins" could be seen as being dynamic
scoping in action.
Regards,
Tony Graham tgraham(_at_)mentea(_dot_)net
Consultant http://www.mentea.net
Mentea 13 Kelly's Bay Beach, Skerries, Co. Dublin, Ireland
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
XML, XSL FO and XSLT consulting, training and programming
[1] 'Because, in a sense, the whole is "bigger" than its parts,
the depth of a hierarchical decomposition is some sort of
logarithm of the ratio of the "sizes" of the whole and the
ultimate smallest parts. From a bit to a few hundred
megabytes, from a microsecond to a half an hour of computing
confronts us with completely baffling ratio of 10^9! The
programmer is in the unique position that his is the only
discipline and profession in which such a gigantic ratio,
which totally baffles our imagination, has to be bridged by a
single technology.'
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html
[2] http://en.wikipedia.org/wiki/Scope_%28computer_science%29#Dynamic_scoping
[3] I think I got the idea from Eric van der Vlist
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--