XInclude: Interpretation of IURIs depends on how the document is included?

I received this example from an implementor:

		test.xml
		<?xml version='1.0'?>
		<root xmlns:xi="http://www.w3.org/2001/XInclude">
		  <xi:include href="inc1.xml"/>
		  <xi:include href="inc1.xml#element(/1/1)" />
		</root>

		Inc1.xml includes inc2.xml from a subdirectory Dir,
which is specified as xml:base attribute on the parent element:

		inc1.xml
		<?xml version='1.0'?>
		<root>
		  <element xml:base="Dir\">
		    <xi:include href="inc2.xml"
xmlns:xi="http://www.w3.org/2001/XInclude">
		      <xi:fallback>Include failed.</xi:fallback>
		    </xi:include>
		  </element>
		</root>

		inc2.xml
		<?xml version='1.0'?>
		<Included_Element/>

		Everything is fine when the whole inc1.xml document is
included via the first <xi:include>. But when just the single <element>
is included, it's xml:base is overridden and the inclusion of inc2.xml
fails. This is the resulting document:

		<?xml version='1.0'?>
		<root xmlns:xi="http://www.w3.org/2001/XInclude">
		  <root xml:base="file:///d:/XmlBaseTest/inc1.xml">
		    <element xml:base="Dir\">
		      <Included_Element
xml:base="file:///d:/XmlBaseTest/Dir/inc2.xml"/>
		    </element>
		  </root>
		  <element xml:base="file:///d:/XmlBaseTest/inc1.xml">
		    Include failed.
		  </element>
		</root>

		So the interpretation of IURIs in Inc1.xml depends on
how the document is included (where the inclusion started).
		Is this expected behavior?


I responded that:

		I believe the correct result should be:

		<?xml version='1.0'?>
		<root xmlns:xi="http://www.w3.org/2001/XInclude">
		  <root xml:base="file:///d:/XmlBaseTest/inc1.xml">
		    <element xml:base="file:///d:/XmlBaseTest/Dir/ ">
		      <Included_Element
xml:base="file:///d:/XmlBaseTest/Dir/xinc2.xml"/>
		    </element>
		  </root>
		  <element xml:base="file:///d:/XmlBaseTest/Dir/">
		      <Included_Element
xml:base="file:///d:/XmlBaseTest/Dir/xinc2.xml"/>
		  </element>
		</root>

		XML Base combines relative values of the xml:base
attribute with the base URI in effect to come up with a final base URI
value. 

The response was:

		You are right. I got thrown off the track by the
'replace' word in "If an xml:base attribute information item is already
present, it is replaced by the new (xml:base) attribute.". When the
xml:base attribute is already on the element and it is absolute, or
relative with the same base as the include parent, the new attribute is
in fact the same as the one that was there. 'Replace' invokes the idea
the xml:base context is actually replaced by the context of the include
parent. 

		Is there a chance that this could me mentioned in the
errata / spec update, e.g. via example?

Thus, I log this on our comments list.