Re: 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.

Untrue.  The XSLT spec leaves plenty of room by not prescribing how 
stylesheets must be parsed, or any pre-stylesheet-processing on stylesheet or 
source document infosets, or post-stylesheet-processing on result tree 
infosets (or I suppose groves in the HTML & text output case, I guess).

For instance, in the HTML output method, Saxon and 4XSLT replace character 
entities including those between   and ÿ are converted to general 
entities such as  .  I see this post-XSLT HTML grove operation which is 
quite legal according to XSLT.

IMO a pre-XSLT expansion of XIncludes in the stylesheet or source documents is 
quite legal as well.

> 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...

I don't know abou this latter part.  I would argue that this is a place where 
conformance in undefined, so any conformance test is broken by the very fact 
of its existence.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@xxxxxxxxxxxxxxx               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python



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