OMG Technology Adoption Process
Part V: The OMG Specification maintenance cycle
|
|
|
|
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.
Top |
|
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 which you can
find out about here.
Top |
|
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.)
Top |
|
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.
Top |
|
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.
Top |
|
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.
Top |
| |
Last updated on
02/14/2013 |
|
