RE: [dita] Versioning of DITA public identifiers

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

Hi Chris - those are changes in the schema, to fix bugs. In those cases,
for example, the <stepxmp> element was identified as
"- topic/itemgroup task/tutorialinfo "
instead of
"- topic/itemgroup task/stepxmp "

The result for all of the class problems listed there is that any
processing rules for working with the element would never fire. I don't
think any processors actually define special behavior for those elements,
which is why the bug was not noticed sooner. Also, the bugs did not exist
in the DTD, only in the schema.

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

"Chris Wong" <cwong@idiominc.com> wrote on 10/13/2006 02:32:37 PM:

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