RE: [dita] strict task vs. general task vs. the file naming and module r

Eliot wrote:

> I don't think it's going to come as a surprise to any 1.1 user that 1.2 is a significant change to DITA.

It might if we continue to claim that DITA 1.2 is compatible with DITA 1.1.

I still hope we do not go forward with option (1), but if we do, I don't think we can continue to claim that DITA 1.2 is compatible with DITA 1.1 and 1.0. Instead I think we'll need to say something like:

ˇ DITA 1.2 is mostly compatible with DITA 1.1 and 1.0.

ˇ DITA 1.2 is largely compatible with DITA 1.1 and 1.0.

ˇ DITA 1.2 is compatible with DITA 1.1 and 1.0 except for the following changes xxxx, xxxx, ..., and xxxx.

ˇ DITA 1.2 is compatible with DITA 1.1 and 1.0 except for the items listed in Appendix XX of the DITA 1.2 Architectural Specification.

Is anyone working on a draft of the “upgrade guide” chapter or document that we’ve said is needed?

Eliot also wrote:

> Note that the issue with the current release of Arbortext Editor 5.4 is

> *not* the result of this design change, it is the result of a mistake made

> by the Arbortext Editor development team.

It is true that the Arbortext development team (that would be me) made a mistake here, but it is also true that the TC distributed a draft version of the ditabase doctype shell that contained a similar mistake. And if we can make this sort of mistake, then others will too. The TC’s mistake will be corrected soon (or quite likely has already been corrected in the DTDs and XSDs that were posted earlier in the week).

And Eliot also wrote:

> So I think we can assume that the current

> Arbortext Issue will be resolved before or very soon after DITA 1.2

> reaches the final stages of approval.

I certainly hope so, but if the TC doesn't make a decision soon we will miss an opportunity to fix this issue in the next maintenance (minor) release for Arbortext Editor. We’ve got about three weeks to go. I guess I can go ahead and make a fix of my own design if the TC doesn’t make a decision in time, but my solution is likely to be option (2) and that may or may not be the solution that the TC ultimately chooses.

I'm thinking of starting a betting pool about if DITA 1.2 will be an officially approved OASIS standard before the next major release of Arbortext Editor comes out. The TC and OASIS have roughly 11 months to get this done to win that race. At this point it is not clear which side of this bet I’ll take myself.

-Jeff

> -----Original Message-----

> From: Eliot Kimber [mailto:ekimber@reallysi.com]

> Sent: Friday, November 13, 2009 3:42 PM

> To: Joann Hackos; Michael Priestley

> Cc: dita; Park Seth-R01164

> Subject: Re: [dita] strict task vs. general task vs. the file naming

> and module rules

> On 11/13/09 2:20 PM, "Joann Hackos" <joann.hackos@comtech-serv.com>

> wrote:

> > HI--

> >

> > I'm really opposed to this option (1). There is absolutely no way we can

> > possibly inform everyone using DITA today that theyšre in for big problems.

> > Are all of the vendors of all the editors willing to place warnings on their

> > releases, which should have happened with Arbortext 5.4? How will we

> > communicate the problem? Most users donšt even know of the existence of

> > dita.xml.org or any of the documentation from either TCs.

> To recap, this change affects the following users:

> - Users using topics that are specialized from task and that *did not*

> define new content models for taskbody. That seems like a very small

> potential set, since most reasons to specialize from task would be to

> further refine the details of the task body (e.g., specialized prerequisite

> markup, etc.), which means your specialization already reflects the 1.1

> strict model and that won't change with a move to 1.2. Any group this

> sophisticated can probably handle the migration without difficulty and

> has, in fact, probably been waiting eagerly to be able to have a more

> flexible topic model to specialize from.

> - Users using local shells for the base task topic type. These users will

> see unconstrained content for topicbody until their shells are updated to

> integrate the TC-provided constraint module. The update task is easy to

> do--just copy the relevant lines from TC-provided task.dtd into your task.dtd.

> This group is probably a *bit* larger, but if my so-far-quixotic attempts to

> get the community at large to understand the need for local shells is any

> indication, there aren't too many groups using local shells. Certainly

> very few users of Arbortext, XMetal, or FrameMaker are.

> Note that the issue with the current release of Arbortext Editor 5.4 is

> *not* the result of this design change, it is the result of a mistake made

> by the Arbortext Editor development team. That mistake can easily be fixed

> by using a fix to 5.4, something PTC will have to do when 1.2 is

> sufficiently stable in any case, in order to reflect other late changes

> we've made to the markup design. So I think we can assume that the current

> Arbortext Issue will be resolved before or very soon after DITA 1.2

> reaches the final stages of approval.

> Oxygen points to strict task because it uses the TC-provided shells and

> modules without modification.

> As far as publicizing the need for migration, I think we can easily include

> an appendix to the 1.2 spec that lists migration items and how to address

> them in moving from 1.1 to 1.2.

> I don't think it's going to come as a surprise to any 1.1 user that 1.2 is a

> significant change to DITA.

> We also have the DITA Users news group as well as the other channels

> used by the DITA Adoption TC.

> Cheers,

> E.

> --

> Eliot Kimber

> Senior Solutions Architect

> "Bringing Strategy, Content, and Technology Together"

> Main: 610.631.6770

> www.reallysi.com

> www.rsuitecms.com

dita message