My gut feeling is that we canât really expect tools to handle all intricacies of changes between 1.3 and 2.0 and perform seamless processing across versions. After all, DITA 2.0 has been dubbed as a version that is incompatible to the previous one. So this
naturally calls for a migration of documents (topics and maps), especially for larger volumes of data.
I agree with Gershon and think that a formal recommendation to process only 1.x or 2.0 data at the same time could help. Iâm open to the question whether to include more details of the kind that Robert outlined in his OP.
I could imagine that tool vendors might find various answers of how to deal with mixed-version doc repositories. For example, in a CCMS, you could analyze existing data, flag 2.0-compliant documents and offer certain operations
only on them. Vice versa, you could offer applying migration steps exclusively for non-2.0 documents.
f.
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.