RE: [dita] Versioning of DITA public identifiers

["Chris Wong" <cwong@idiominc.com>]

Regarding class attributes, I was thinking of the bug fixes listed in
http://wiki.oasis-open.org/dita/Bug_fixes_for_DITA_1.1. Some of those
fixes imply class attribute changes. My apologies if I misunderstood.

Chris 

-----Original Message-----
From: Robert D Anderson [mailto:robander@us.ibm.com] 
Sent: Friday, October 13, 2006 3:27 PM
To: Chris Wong
Cc: dita@lists.oasis-open.org
Subject: RE: [dita] Versioning of DITA public identifiers

I don't know why it is FIXED either. Does anybody have a problem with
making this attribute CDATA?

Regarding class attributes -- Chris, can you give an example of a class
attribute that has changed? Other than in bookmap (which was not part of
the standard, and does have new OASIS public IDs), these values should
not have changed. Some of the class attribute definitions have moved
into different DTD modules, but the content should be the same.

For the public IDs -- would it help if the catalog we provide declares
both public IDs with version, and version-agnostic values that always
point to the latest? We could have all three of these public IDs:
-//OASIS//DTD DITA Concept//EN
-//OASIS//DTD DITA 1.0 Concept//EN
-//OASIS//DTD DITA 1.1 Concept//EN

The first points to the latest, the second means 1.0, and the third is
1.1.
I realize that this is not ideal, because already with the new release,
the generic one will change to 1.1. However, other than the
DITAArchVersion attribute that I think we should correct, I think that
it should really be possible to swap in the new set of DTDs.

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit
(507) 253-8787, T/L 553-8787


 

             "Chris Wong"

             <cwong@idiominc.c

             om>
To 
                                       "Grosso, Paul" <pgrosso@ptc.com>,

             10/13/2006 01:34          <dita@lists.oasis-open.org>

             PM
cc 
 

 
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


 From: Scott Hudson [mailto:scott.hudson@flatironssolutions.com]
 Sent: Monday, 2006 October 09 13:11
 To: dita@lists.oasis-open.org
 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.ph
p?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