strict task vs. general task vs. the file naming and module rules

From
Fershon Ioseph <>
Date
2009-11-16T10:21:00+00:00
ID
Thread
strict task vs. general task vs. the file naming and module rules
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