[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] strict task vs. general task vs. the file naming and module rules
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]