For discussion - what does it mean to mix DITA 1.3 and 2.0?

[Robert Anderson <robert.dan.anderson@oracle.com>]

This question came up in an implementation discussion, with some implications I had not previously considered.

I've been asked about mixing 1.3 and 2.0 in several venues, and have always said that I think this is largely up to implementations but that I expect most tools will let you mix 1.3 and 2.0 topics as part of the same map. If a tool claims to support both versions, then it has the grammar files to parse them and will accurately read and handle the files. There may be hiccups in some cases, such as trying to conref across versions, so you should check with your application before planning on such a split environment.

But what about maps, where so much of DITA processing is built around the idea of a single resolved map context (key space, cascading/inheritance of metadata, etc)? The grammar part still seems clear to me - you can parse a 2.0 root map and parse a 1.3 submap because you have the DTD/RNG. But how does that impact processing, and what should applications expect? This gets more complicated:

• DITA 2.0 uses chunk="combine" in the way DITA 1.3 uses chunk="to-content". Assume a DITA 2.0 root map with a DITA 1.3 submap, where a branch in that submap uses chunk="to-content". In a resolved map context, you've got one map structure that looks like 2.0, but with a mix of DITA 1.x and 2.0 processing tokens. Do applications need to handle both in the same root map context? Do they have to support only "to-content" for the 1.3 part of the map structure, and only "combine" for the 2.0 part?
• What about the reverse, a DITA 1.3 root map that pulls in a 2.0 submap containing chunk="combine"?
• If my application keys off of the DITA 2.0 version in a root map, what does it do with obsolete DITA 1.3 markup in a submap?
• The <navtitle> element is handled very differently in 1.x and 2.0. If you have a 2.0 root map, what should an application do with <navtitle> in a DITA 1.x submap -- treat it as a hint (1.3 behavior) or as an actual title (2.0 behavior)?

My take on all of this is basically -- we have a 1.3 standard, and a 2.0 standard, we do not have a 'mix of both' standard, so it is up to implementations how to handle this, if they can handle it at all. They also should probably define and document their expected behavior.

If that's the case, does the TC need to make an official statement to that effect, or even put a note about compatibility in an appendix for the 2.0 spec? I believe the only alternative where this is notâ up to implementations is if the TC develops a full compatibility spec, with normative rules about how each modified feature interacts in different scenarios. At the moment that feels like a really big task, so I don't see it happening as part of the spec.

Thanks,

Robert