This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: XInclude in Cocoon
- To: xsl-list at lists dot mulberrytech dot com
- Subject: RE: [xsl] XInclude in Cocoon
- From: Dylan Walsh <Dylan dot Walsh at Kadius dot com>
- Date: Fri, 9 Feb 2001 10:45:39 -0000
- Reply-To: xsl-list at lists dot mulberrytech dot com
I would assume that when the XSLT part of (framework such as Cocoon) sees
the stylesheet, the inclusion has either been performed, so it sees the
substituted elements not the XInclude, or else it sees an XInclude element
that it treats as an LRE.
There would be no violation of the XSLT recommendation - XInclude is
performed either before or after XSLT.
> -----Original Message-----
> From: Michael Kay [SMTP:mhkay@iclway.co.uk]
> Sent: Friday, February 09, 2001 8:58 AM
> To: xsl-list@lists.mulberrytech.com
> Subject: RE: [xsl] XInclude in Cocoon
>
> > The XInclude spec defines a way to express inclusions, but makes no
> > prescriptions of the semantics of such inclusions. An XSLT
> > processor can
> > choose to expand the include or pass it on, and in both cases
> > be conformant to XInclude and XSLT.
>
> I'm not sure it would be conformant to XSLT. The XSLT spec leaves no room
> to
> treat xinclude:include as anything other that a literal result element, if
> it appears in the source tree. You could argue that XSLT says nothing
> about
> how the source tree is created, and therefore it doesn't care whether
> xinclude is expanded during a preprocessing phase; and I suppose you could
> argue that no conformance test can tell the difference...
>
> Mike Kay
>
>
> XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list