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

My preference is to make a formal TC statement that users should ensure their content is all 2.0 or all 1.x. Some tools donât support multiple versions of the DITA DTDs. In fact, when we integrated our PC-DITA specializations into the CCMS used at my current primary client, we had to redo our specializations to use the DITA 1.3 DTDs, because thatâs what the CCMS was using and they said they donât support multiple DITA versions, not even 1.2 and 1.3â

Cheers,

Gershon

Gershon JosephÂ|ÂSenior Information Architect |ÂPrecision ContentÂ
Direct:Â+972 (54) 658-3887|ÂEmail:Âgershon@precisioncontent.comÂ| www.precisioncontent.com

Unlock the Knowledge in Your Enterpriseâ

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.ÂPlease notify us by return email if you have received this email in error.ÂÂ2021, Precision Content Authoring Solutions Inc, Toronto, Ontario, Canada

From: dita@lists.oasis-open.org <dita@lists.oasis-open.org> on behalf of Robert Anderson <robert.dan.anderson@oracle.com>
Date: Tuesday, 21 December 2021 at 16:42
To: dita@lists.oasis-open.org <dita@lists.oasis-open.org>
Subject: [dita] For discussion - what does it mean to mix DITA 1.3 and 2.0?

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

dita message