[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Re: Re: Re: Reliance on import precedence consider

Subject: Re: Re: Re: Re: Reliance on import precedence considered dangerous
From: Dimitre Novatchev <dnovatchev@xxxxxxxxx>
Date: Sat, 17 Feb 2001 22:49:12 -0800 (PST)
reliance company problem
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.

Cheers,
Dimitre.

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.