Re: [xsl] Re: Re: Re: Reliance on import precedence considered dangerous

Subject: Re: [xsl] Re: Re: Re: Reliance on import precedence considered dangerous
From: Dimitre Novatchev <dnovatchev@xxxxxxxxx>
Date: Sat, 17 Feb 2001 22:49:12 -0800 (PST)
Hi Jeni,

This is a big step forward since you now realise that implementing xsl:import 
with the "virtual" attribute will eliminate the problems of having the same stylesheet
imported twice.

This was your original problem and you were complaining that this came to you as a surprise,
because its reasons were not obvious and were never explained in documentation.

I fully agreed with your initial argumentation and this is why I proposed a solution, analogous to
the "virtual base class" in C++.

> >> Having thought about it some more, the real issue is if both B & C
> >> (which both import D and are both imported by A) override something
> >> in D in different ways. I don't think(?) that a virtual attribute
> >> would address this problem?
> >
> > It will, because there will not be a second imported identical
> > stylesheet that precedes some overrides.
> Sorry, I was talking here about:
>       B -- D
>      /
>   A +
>      \
>       C -- D
> where B and C both contain the same named template. They both happen
> to be overriding the same named template in D (which is how come they
> have the same name), but that's really by the by. In terms of this
> particular template, you can forget about D - it's not important. The
> tree may as well look like:
>       B
>      /
>   A +
>      \
>       C
> There are no identical stylesheets in this situation but the problem
> (of a stylesheet no longer behaving as it did when it was standalone)
> still occurs as the template in C overrides the template in B.

Now you're changing directions and only complain that because of higher import precedence an
overriding template from C will also override an overriding template from B.

But this is exactly "as expected" -- this is  the behaviour by design. Nobody can say that this
"came as surprise".

Again to parallel this with an OOPL, ambiguity has to be resolved in some way, or to be reported
as error. The import precedence in XSLT serves to resolve ambiguity.

Someone raised yesterday the idea of "lint stylesheet" checking for non-portability.

The scope of such tool could be extended to report any "dead" (never to be activated) templates
due to other existing templates with higher import precedence.


Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!

 XSL-List info and archive:

Current Thread