This is what the xinclude W3C standard is for. Similar to the external entities approach (as in above answer), you can encode the content-to-be-included in a separate file, like e.g. (frag.xml):
<a><!-- huge content --></a>
In the main XML file, an xinclude instruction refers to this external content:
<document>
<xi:include href="frag.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
<b/>
</document>
When processed with an (xinclude-capable) XML processor (like e.g. Xerces http://xerces.apache.org/
), the parser will expand this xinclude instruction with the contents it points at. The inclusion target in the @href attribute is interpreted as a URI, so you can equally point to fragments using fragment identifiers (e.g. href="frag.xml#fragment1
).
Besides simple URIs in @href, the xinclude standard supports a very fine-grained vocabulary for expressing the inclusion target in a @xpointer attribute. However, support for complex XPointer expressions depends on the processor's XPointer compliance, which is generally underused. However, there's a (minimal) XSLT implementation as well: XIPr (http://dret.net/projects/xipr/
).