dita — archive

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

From: Kristen Eberlein
To: [email protected]
Date: Tue, 21 Dec 2021 15:47:00 -0000

I do not think that is an appropriate statement for the spec to make. The DITA TC defines the standard; we do not pronounce best practices for implementations. This is really a tooling/processing consideration that relates to the intricacies of handling two versions of the specification. If tools cannot support two versions of the DITA grammar files, I think that speaks to the limitations of the CCM systems. Our job as the TC is not enable CCM systems to work with their current limitations! Best, Kris Kristen James Eberlein Chair, OASIS DITA Technical Committee OASIS Distinguished Contributor Principal consultant, Eberlein Consulting LLC www.eberleinconsulting.com +1 919 622-1501; kriseberlein (skype) On 12/21/2021 9:52 AM, Gershon Joseph wrote: 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: [email protected] 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. 20 21 , Precision Content Authoring Solutions Inc, Toronto , Ontario, Canada From: [email protected] <[email protected]> on behalf of Robert Anderson <[email protected]> Date: Tuesday, 21 December 2021 at 16:42 To: [email protected] <[email protected]> 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