[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: 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 Unlock the Knowledge in Your Enterpriseâ
From:
dita@lists.oasis-open.org <dita@lists.oasis-open.org> on behalf of 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:
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]