Re: [xsl] stylesheet organisation

Subject: Re: [xsl] stylesheet organisation
From: "Tony Graham" <tgraham@xxxxxxxxxx>
Date: Sun, 4 Sep 2011 18:19:45 +0100 (IST)
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@xxxxxxxxxx
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

Current Thread