We should submit a version for
public review that we feel is final and ready to become a standard. If we
need to make changes in response to comments received during the public review
to improve or clarify the language, we can do that, but we shouldn’t
submit something knowing that we want to make more changes.
Several of the issues that are
pending before the TC are quite substantive and it feels as if more such
issues are raised each week. We either need to find a way to defer those
items to DITA 1.3 or we need to take the time to deal with them well.
-Jeff
From: Gershon Joseph
(gerjosep) [mailto:]
Sent: Monday, November 16, 2009 5:20 AM
To: Grosso, Paul; dita
Subject: RE: [dita] Release date
AFAIK the OASIS procedure states that a spec sent out for public
review must be final. Minor updates to language to clarify things is permitted,
as are fixes to typos etc. However, any change to the normative spec that is
not just cleaning up the language requires the process to be started again. I
think it's unfair to submit an incomplete spec to public review, since we would
need to resubmit it after we finish our spec development work. It would be
unfair on our TC admin, who has to do quite a bit of behind the scenes work in
order to release a spec into the approval workflow, and it would also be unfair
to the general OASIS members who would review the incomplete spec and then be
asked to re-review it a few months later.
The TC needs to finish our design and development work and
complete the spec documentation before we initiate the OASIS review workflow.
--
Gershon
From: Grosso, Paul [mailto:]
Sent: Saturday, November 14, 2009 5:43 PM
To: dita
Subject: RE: [dita] Release date
I'm not sure if there is an OASIS policy on this or not, but I
don't think we should issue a spec for public review unless we think it is
ready for public review, and that means that we as a TC think it is ready for
publication except for truly editorial nits. And the kind of wholesale
rewriting and redefining of terminology--to say nothing of the issue of general
versus strict task--go way beyond editorial nits.
So I would be against issuing the spec for public review until it
is really ready for it. And we still have to do our last non-public
review first.
paul
From: Bruce Nevin
(bnevin) [mailto:]
Sent: Friday, 2009 November 13 15:54
To: dita
Subject: [dita] Release date
From: Ogden, Jeff [mailto:]
Sent: Friday, November 13, 2009 4:27 PM
To: Eliot Kimber; Joann Hackos; Michael Priestley
Cc: dita; Park Seth-R01164
Subject: RE: [dita] strict task vs. general task vs. the file naming and
module rules
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
A lot of our time consuming work now is on the spec. Would it
speed the process if we plan to make additional spec refinements during and
after public review? I don't know the process, but don't we expect that we
might have changes come out of public review? Planning for that, couldn't
we identify some of the known readability and presentation issues that we would
like to make better, and plan to do them in that time frame so that we can
concentrate on the accuracy and substance issues before release for public
review?
/Bruce
