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