RE: [dita] Versioning of DITA public identifiers

[Robert D Anderson <robander@us.ibm.com>]

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.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