W3C home > Mailing lists > Public > www-xml-xinclude-comments@w3.org > May 2000

RE: Using XInclude with XSLT transformations

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Thu, 18 May 2000 15:07:01 -0700
Message-ID: <116DFD732FA92E4D9B647C8EEF6DAF10155920@red-pt-02.redmond.corp.microsoft.com>
To: "'Eric van der Vlist'" <vdv@dyomedea.com>, www-xml-xinclude-comments@w3.org
The original goal was for XInclude to be transparent.  Your comment fuels my
suspicion that this may not be the best direction.  While it's pretty
difficult procedurally for us to define XPath extensions (this should be
left to the XPath's owner groups), I think it does make a lot of sense to
add an optional property to the result infoset that would provide
information about the source of the include.  I'll bring this issue up to
the WG.


- Jonathan Marh

> -----Original Message-----
> From: Eric van der Vlist [mailto:vdv@dyomedea.com]
> Sent: Wednesday, May 17, 2000 5:58 AM
> To: www-xml-xinclude-comments@w3.org
> Subject: Using XInclude with XSLT transformations
> A long discussion is taking place on the XSL-LIST about the usage
> of external parsed entities with XSLT and the question might be : 
> "will XInclude work better than external parsed entities with XML 
> tools such as XSLT ?".
> Using external parsed entities to include sub-documents is a common
> practice which is illustrated [1], for instance, by the docbook 
> recommendations.
> Transformation tools based upon standard XML parsers which silently
> resolve the external entities references, such as XSLT, can't 
> be used to
> transform documents containing external parsed entities without losing
> the document include structure.
> A common practice [2] used as a workaround is to create links in your 
> documents and to switch between documents in your transformation, 
> the downside being that you are losing the possibility to do global 
> XPath queries on multiple documents.
> While the syntax of this simple mechanism is in many ways similar to
> XInclude, the XInclude Working Draft describes the merge of 
> the included
> documents as transparent for the application :
> "The acquired infoset is merged with the source infoset to 
> create a new
> infoset by replacing the information items representing the
> xinclude:include elements with information items in the acquired
> infoset. The xinclude:include element, its attributes and any 
> children,
> are not represented in the result infoset."
> Following this rule in a XSLT transformation wouldn't allow to handle
> XInclude any better than external parsed entities. 
> While I don't see any easy solution to this problem, as a XSLT user, I
> think the inclusion process should add extra nodes to the XPath Object
> Model and (maybe though a new axis), to optionally specify if you want
> to access the merged or the initial infoset.
> Best regards
> Eric van der Vlist
> References :
> [1] http://www.mulberrytech.com/xsl/xsl-list/archive/msg12531.html
> [2] http://www.mulberrytech.com/xsl/xsl-list/archive/msg12538.html
> -- 
> --------------------------------------------------------------
> ----------
> Eric van der Vlist       Dyomedea                    
http://xmlfr.org         http://4xt.org              http://ducotede.com
Received on Thursday, 18 May 2000 18:08:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:58:55 UTC