I believe the DITAArchVersion
was changed to 1.1 so processors can distinguish between DITA 1.0 and
1.1
content.
Is there a reason why it has to be FIXED? The @class and @domains
attributes are not FIXED, after all. Remove the FIXED type for
DITAArchVersion, and the XML will parse.
But the wider issue is that "fixed"
attribute values will change from one set of DTDs to another. Even if
they are not technically of FIXED type, the DTDs can have different
values. Several elements' @class values have changed in the DITA 1.1
DTDs. So even if your DITA 1.0 source parses with the new DITA 1.1
DTDs, any @class values in there could be incorrect from DITA 1.1's
perspective. I can't imagine any DITA version migration without some
automated cleaning up of attributes: you can't just swap in a fresh set
of DTDs.
Is it too late to consider adding the
version number to the public ID? I had not realized that this proposal
was dropped from DITA 1.1. At least in the transition from DITA 1.3.2
to OASIS DITA 1.0, the different public IDs allowed us to distinguish
between DITA versions in the DOCTYPE declaration. DITA 1.1 would be the
first DITA release where we cannot distinguish between DITA DTD
versions.
Chris
I started to write (read to the
end of extract before you reply):
[[
I might be missing or forgetting
something, but I don't think there is a problem,
and I am quite sure I don't want
to version DITA's public identifier (which is
I think what you mean by "versioning the DOCTYPE
DECL for DITA 1.1").
We designed 1.1 to be upward
compatible with 1.0, and content isn't versioned,
so I don't see what it means to
be "1.0 content" so I don't see what it means
to have "a mix of 1.1 and 1.0 topics".
If you have a 1.0 DTD and you
try to validate content that uses things added
in 1.1, it won't validate. So
don't do that. You can't expect an old system to
handle new stuff. Upgrade your
system to use the DITA 1.1 application.
Now your new system should work
fine on all your DITA (1.0 and 1.1) content.
]]
and then I checked and noted
that we are setting the DITAArchVersion to 1.1
and making it FIXED in the 1.1
DTDs.
As long as your editor doesn't
explicitly set DITAArchVersion and your application
doesn't push defaulted values
from the DTD into the instance, you'll be okay, but
if your application does push
defaulted values from the DTD into the instance
(which I'm guessing Documentum
might do), I can see that you are versioning
your content, and then I do see
Scott's problem (though I still don't think the
solution is to version the
public identifier).
If 1.1 is upward compatible with
1.0, then why are we changing the value of the
DITAArchVersion attribute? And
do we really want it to be fixed?
paul
Where did we (DITA TC) end up on versioning the DOCTYPE DECL for DITA
1.1?
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