[chairs] RE: TC coordination (was: Re: OASIS given liaison membershipat JTC1 SC34)

["Karl F. Best" <karl.best@oasis-open.org>]

Jon:

> I'm sorry, but if we're controlling the architecture, then we are
> implicitly controlling the scope of the TCs.  There's no way
> around that.

This is not intended as a control mechanism but as a coordinative
mechanism. Nobody has said anything about imposing an architecture on
any of the TCs, but working with the TCs to develop a common
architecture so that the resulting specifications can work as a cohesive
whole. The Board has agreed with this principle; they recognize that a
set of interoperable specs are much more valuable than a bunch of
stand-alone specs. But there's room for both: if a TC wants to develop a
spec that stands alone it is still free to do so. No TC would be forced
to conform.

> The OASIS TC process was designed to allow competition at the
> specification level so that freely competing specifications could
> be sorted and graded in a second phase run by different rules. In
> the OASIS process this second round is the standardization phase,
> and it's here that OASIS as an organization is supposed to apply
> the control that Karl is seeking to exercise at the specification
> level.  In the standardization phase, OASIS as a corporation
> decides which of the competing specifications gets to be a
> standard based on the general quality of its design, its success
> among implementors, and its acceptance by the general community.

You assume that OASIS builds only competing, stand-alone specifications
of which only few should survive. What have you got against
complimentary, interoperable specifications? Why cannot, for example,
the set of ebXML specifications be built as pieces of a whole? Or
security? or web services? or topic maps?

Obviously our visions are different.

> We spent two years putting this process in place, and so far it
> seems to be working very nicely within its design constraints. It
> would probably be best to leave the process alone for a while and
> try out the coordinative mechanisms it already supports.

Yes, it's worked well for attracting and encouraging the creation of new
TCs -- we've grown from six to 26 TCs since the Process was adopted a
year and a half ago. But it's going to start failing us very quickly in
regards to the quality of the specifications produced under it. Your
answer will be that if the specs are not of sufficient quality then they
won't be adopted by members, and yes, that is the gating factor. But
shouldn't we be putting just as much effort into improving the quality
of the specs during development as we do to making sure that they don't
get approved if they're not what we want?

> Jon Bosak
> Chair of the OASIS Process Advisory Committee, 1999-2001

You obviously feel a great deal of pride of ownership of the TC Process.
As well you should; you put a lot of effort into its development, and
assembled a fine team of experts to work with you to fine tune it. But
you also acknowledged at the time that it would need to be tweaked over
time as we learned how it worked. I live with this process every day and
make sure that it is working for 26 different TCs. I am constantly
seeking ways to promote OASIS, its members, and the specifications the
TCs produce while working within the constraints -- and yes, the
philosophy too -- of the TC Process. The industry and our members want
specs that work together. They don't want to see OASIS producing a
hodge-podge of ill-conceived specs that are heading in a dozen different
directions. This is about enhancing OASIS' reputation and credibility,
and that of the work we produce, while still being governed by the
sacred bottom-up, member-driven approach.

</karl>
=================================================================
Karl F. Best
OASIS - Director, Technical Operations
978.667.5115 x206
karl.best@oasis-open.org  http://www.oasis-open.org