Yes, of course one can implement Xinclude using the facilities 
in XSLT. That is all well and good. However, if the W3C is 
going to have a standard called xinclude you would expect tools 
that process xml to at least provide the option of recognizing 
it. In other words, I should be able to author a stylesheet 
that transforms a document with out necessarily worrying if the 
author of the document created a monolithic document or created 
a document that xincludes sub-documents. 

Now I know how to create a stylesheet that will work in both 
cases. This is not my question or problem. My question is why 
have a standard if something as ubiquitous as XSLT does not 
recognize it for free?

---- On Thu, 30 May 2002, Joerg Heinicke 
(joerg.heinicke@xxxxxx) wrote:

> Sal Mangano wrote:
>  > Are xslt processors required to use XML parsers that 
recognize and
>  > implement xinclude (http://www.w3.org/2001/XInclude)? If 
not, will they
>  > when it becomes an official recommendation of the W3C? Do 
any processors
>  > recognize it already?
>  >
>  > By "recognize" I, of course, mean "implement" such that 
the referenced
>  > document is merged into the including document.
> 
> Again the question: Why should an XSLT-processor should 
implement XInclude? 
> XPath has a document()-function to work with different files. 
For XInclude 
> you need of course an XInclude-transformer. It's more for XML-
aggregation 
> than transformation. But you can reach the same via document
() I think.
> 
> Joerg
> 
> -- 
> 
> System Development
> VIRBUS AG
> Fon  +49(0)341-979-7419
> Fax  +49(0)341-979-7409
> joerg.heinicke@xxxxxxxxx
> www.virbus.de
> 
> 
>  XSL-List info and archive:  
http://www.mulberrytech.com/xsl/xsl-list
> 
> 
> 


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