From the open action items list
(http://www.oasis-open.org/apps/org/workgroup/dita/members/action_item.php?action_item_id=1016)
this still appears to be an open item.
I understand that if you create a specialization, you are creating a new
public identifier for it. The problem is more around content that is
validating against the base DITA standard.
Currently, (as I understand it), the base DTDs will not have a version
number embedded in the public identifier, even though the DTD has
changed. This was a
"conscious" design feature to not embed version info in an attempt to
continue backwards compatibility.
Unfortunately, this means you may have 1.1 content that would not
validate against a 1.0 DTD, and the system wouldn't be able to tell
which DTD it should use to validate the content against. It also would
fail in a hybrid doc, where there is a mix of 1.1 and 1.0 topics.
If the DOCTYPE DECL is not rev'd, it's going to wreak havoc with
Documentum XML apps. Since the version number is embedded as a fixed
CDATA element, files that were checked into the store will no longer
parse correctly if the DTD is upgraded. The only way to fix this
problem to make a new XML application for each DTD version. To upgrade a
document that previously exists in the Docbase, you have to export
it, change the version numbers and then re-import it so that it gets
associated with the "correct" app.
Here's what happens when we try to import a "new" version document with
the "old" DTD:
Attribute "ditaarch:DITAArchVersion" with value "1.1" must have a value
of
"1.0". Line 86, column 64
,file:C:/Documentum/contentXfer/webtop/sqlserver-2006.10.06-1131h.50s_42
085/
128215d1q10e1eae52ac1q1d8000/10042122.xml
Another area that this affects is XML Catalogs; It's been standard
practice to put the version in the Public ID so that you can include and
reference specific DTD instances locally (typical scenario is to have a
"stable version" and a "test version" of different versions of a DTD to
evaluate compatibility issues). Most catalog resolvers key on the Public
ID to look for a local reference of a DTD.
Based on previous threads, I know that the catalog issue has been pushed
to DITA 1.2, however, I think the DTD rev issue is something we need to
address in DITA 1.1.
Best regards,
--Scott
