[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Versioning of DITA public identifiers
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:pgrosso@ptc.com] Sent: Monday, October 09, 2006 2:35 PM To: dita@lists.oasis-open.org 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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]