Fragment Insertion - is this a bug?

[yamahito]

Hi,
I am having some issues debugging the placement of a fragment insertion using Author actions: can someone confirm if this is a bug in the software, or the user ?
I have a structure like this:

Code: Select all

<document>
	<div class="activity-item">
		<p/>
		<!-- I want to insert <something/> here -->
	</div>
	<xi:include><!-- The content ends up appearing here --></xi:include>
</document>

My action uses the built-in InsertOrReplaceFragmentOperation with the following options:
Activation XPath: ancestor-or-self::div[@class="activity-item"][not(child::something)]
fragment: <something/>
InsertLocation: ancestor-or-self::div[@class="activity-item"]
InsertPosition: Inside as last child

Can anyone give me a pointer as to why the content ends up in the wrong place and/or confirm I'm doing the right thing? Oxygen version is <oXygen/> XML Editor 26.1, build 2024091606

[yamahito]

Also replicated with v27.0

Interestingly, if I remove the following xi:include content, it gets put in the right place.

[xephon]

Your XPath ancestor-or-self gives Oxygen a lot of flexibility to insert the content. Have you tried making it more specific, like self::div[@class="activity-item"]? Maybe this changes the behavior.

[alex_jitianu]

Hi,
The InsertOrReplaceFragmentOperation has a schemaAware parameter that kicks in when the fragment to insert is not valid at the insert location. When that happens it will search for a valid location and insert it there. To see if that is to blame, set schemaAware to false on the operation.

If we find that this parameter is to blame, ca you please double check if the <somenting/> fragment is really valid in the <div/> ? You could paste it in the text page and see what error you receive.

Best regards,
Alex

[Radu]

Hi,
Sometimes when evaluating xpath expressions we treat xi:includes as transparent in the Author visual editing mode.
Where is the caret placed in the XML document when invoking the action?
Regards,
Radu