The OMG Specification Maintenance Cycle
- What is an RTF?
- Who can submit maintenance issues to an RTF?
- What does the RTF do? What can't it do?
- How does the RTF output get adopted?
- And the cycle continues, I suppose?
- What if I need an issue resolved quickly?
What is an RTF?
Active OMG specifications are maintained by a series of Revision Task Forces (RTF). The first RTF is chartered immediately following adoption of an FTF output document as available technology. For the first few years of a specification's life, it will probably have a continuous sequence of RTFs; once the specification becomes stable and few issues are raised against it, there may be intervals when no RTF exists. During these gaps, the raising of a significant issue typically serves as a "wake up call" to form an RTF that can deal with it.
Just like the FTFs that we just discussed, RTFs are composed of members elected by the TC that adopted the specification that it is responsible for. At formation time, an RTF is assigned a comment deadline and report deadline. These deadlines are posted on the RTF's web page. For details on an RTF's deadlines, membership, and assigned task, go to the Work in Progress page and click on its RTF item. On the page that comes up, you'll find its deadlines and voting list.
Who can submit maintenance issues to an RTF?
Anyone, whether they work for an OMG member company or not, may submit an issue against an OMG specification by filling in this form.
OMG RTFs (and FTFs) deal with specification issues only. If you have an issue with a piece of software, you'll have to take it up with the company that produced it.
And, if you're concerned with whether or not an ORB implementation conforms to a specification, we have a source for information on this too but it's not OMG. It's The Open Group, which (yes, in cooperation with OMG) runs a compliance testing program.
What does the RTF do? What can't it do?
OMG staff collect all submitted issues in a database, filed by specification and date. You can view all of the issues filed against our various specifications here, where they are sorted by specification and, therefore, by RTF.
All issues received by the RTF's comment deadline must be acted up on (although "defer" is considered a valid action). The TF may also choose to act on issues received after the deadline, on an individual basis. If not acted on, comments received after the deadline are automatically deferred and held for the next RTF cycle.
Issues typically sort into three categories:
- Actual errors in the specification;
- Ambiguities in the specification; and
- Requests for enhancement to the specification.
Of these, the RTF deals with the first two and archives the last: Enhancements must go through the RFP process, so these requests are saved for the working group that writes the RFP for the next full release of the specification.
Typically working over email, the RTF resolves as many issues as it can during the time allowed. If your company is an OMG member, you can sign up for the email list of any (or all!) OMG RTF, and follow (or even participate in) its deliberations.
RTFs must resolve, write up, and vote out all of their issues by their report deadline because, as of that date, the RTF ceases to exist and can no longer transact business. (Only the RTF vote must precede the deadline; AB, TC, and BOD votes may follow it.)
How does the RTF output Get adopted?
Some RTFs produce their output in the form of a report; others edit their changes directly into the current version of the specification.
Regardless of the form the output takes, it must go through the usual series of votes: The RTF votes, taken issue-by-issue as it works its way through the database, constitute a vote to recommend their output to their parent TC. The report goes to the AB first, then to the TC, and finally to the BOD which also requires a positive acknowledgement from the BSC which asks the members for a commitment to market a product conforming to the revised specification. Because the commitment does not extend beyond the revision under vote, there is no veto power associated with this.
Following BOD approval, the output is edited into the previous version of the specification by OMG's editing staff (if the RTF didn't do this themselves). The final version becomes the next point release.
And the cycle continues, I suppose ?
You suppose correctly. Following an RTF deadline, another RTF is typically formed and the cycle starts over.
Once a specification stabilizes and issues no longer accumulate, OMG members may let time go by between the conclusion of one RTF and the start of the next. However, if a substantial issue comes up, a new RTF will probably be chartered to deal with it.
What if I need an issue resolved quickly?
Some critical issues are dealt with on an expedited basis. The decision to expedite is made by OMG, and only for issues rated as "critical" by the person who submits them. (There's a place on the form to rate the severity of the error you're reporting.) This procedure is not undertaken lightly. You should only check "critical" if your company is building a product based on an OMG specification and you encounter an error that keeps you from continuing with your work.