This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: xsl:include is necessary after all
- To: <xsl-list at lists dot mulberrytech dot com>
- Subject: RE: [xsl] xsl:include is necessary after all
- From: "Evan Lenz" <elenz at xyzfind dot com>
- Date: Fri, 18 May 2001 10:18:23 -0700
- Reply-To: xsl-list at lists dot mulberrytech dot com
> -----Original Message-----
> From: Evan Lenz [mailto:elenz@xyzfind.com]
> Sent: Friday, May 18, 2001 10:09 AM
> To: xsl-list@lists.mulberrytech.com
> Subject: RE: [xsl] xsl:include is necessary after all
>
>
>
> > Not fine. The *-template caught most of the elements since the templates
> > from B.xsl had no chance to match anything. So I had to modify
> > the xsl:import
> > in A.xsl to xsl:include. Since A.xsl was not my invention I would rather
> > leave this stylesheet unchanged.
> >
> > Is this something the WG should consider when developing XSLT 2.0?
>
> Besides breaking existing stylesheets, what sorts of issues would
> arise if conflicts were resolved the other way around instead
> (priority first and *then* import precedence)?
>
> Evan
In other words, what if import precedence was used simply to resolve
conflicts between template rules of equal priority, and that would otherwise
be illegal (if the implementor chooses to catch the error at compile-time)?
This was my incorrect understanding of how it worked. Is there an inherent
problem with this (besides backward-compatibility)?
Evan
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list