What are the rules for nested conrefs within a conref push?

[ChrisTrenkamp]

I've searched the spec for an answer to this question to no avail: what happens when there's another conref within a conref push? The rules are clear with nested pulls, but it's not very clear with pushes.

<!-- source.dita -->
<p conaction="pushreplace" conref="other.dita#topic/ptag">
  <codeblock conaction="pushreplace" conref="#./codetag">codeblock</codeblock>
</p>
<codeblock id="codetag">will this get replaced?</codeblock>
<!-- ... or what about... -->
<p conaction="pushreplace" conref="other.dita#topic/ptag">
  <codeblock conref="#./codetag">codeblock</codeblock>
</p>
<codeblock id="codetag">will this be pulled?</codeblock>

What's supposed to happen with the codeblock tag in cases like these? Does the codeblock's source document effectively become other.dita and gets resolved from there? Does the codeblock's source document stay under source.dita? Is this forbidden?

[robander]

We discussed this as the OASIS TC on Tuesday, and the general thinking was along the lines of -- what's inside a block is resolved in the new context, the same way it would be for XREF.

As I write that up here though I'm not sure it's workable -- that design works because XREF is pretty much always evaluated after conref or conref-push, because it's something that you can hold off almost until rendering time.

If conref and conref-push are evaluated separately (which they are today in DITA-OT, and maybe / probably in other tools), this doesn't work. Whichever is processed first is handled in that context, whether it is inside or outside.

I think I'll have to raise that issue with the TC again next week, and hopefully come back with a clearer answer. Whatever the answer, it seems clear we need to address it in the next specification update.

[robander]

Discussed again today, and I brought up the assessment I had above. The TC agreed today that this condition is ambiguous in the DITA 1.3 specification, so we do not really have an answer about what is correct.

There is an open item for DITA 2.0 to mandate a processing order; we will plan to address this specific condition as part of that issue (issue #30).