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
From: Grosso, Paul [mailto:]
Sent: Monday, October 09, 2006 2:35 PM
To:
Subject: RE: [dita] Versioning of DITA
public identifiers
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
From: Scott Hudson
[mailto:]
Sent: Monday, 2006
October 09 13:11
To:
Subject:
[dita] Versioning of DITA public identifiers
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
