001. Why Robert's won't work

[Jon Bosak <bosak@boethius.eng.sun.com>]

[Terry Allen:]

| Robert's is pretty well written.  I don't mind using it to
| run OASIS as a whole - Jon has made an excellent argument
| for that (it's what I deleted), but on the other hand this
| application of Robert's to TC process specifically results
| in something drastically different from the IETF process,
| which we know works, in the sense of producing
| specifications.  So I would be more convinced that Robert's
| will be better for TCs if I knew of committees similarly
| productive to the IETF that operated using Robert's.

ANSI uses Robert's; probably many other U.S. standards bodies, too.
You can accuse these groups of lots of things, but a lack of
productivity isn't one of them.

However, I now consider this point to be moot.  I don't think we can
use Robert's itself for the committee process.

When I was in Japan last week, I spoke before two fairly influential
groups interested in XML and told them that they should participate
more actively in OASIS.  After both presentations I was told by highly
respectable people that the language barrier was too high and that we
should form an OASIS Japan.

The idea of instituting a whole a corporate substructure for each
linguistic community doesn't scale, of course.  What works here are
lots of committees for information exchange formed within specific
trading communities that might happen to operate in a single
linguistic space and therefore might want to conduct their business in
a language other than English.  But hearing about the language barrier
after presentations to two different groups made rather an impression
on me.

I think it's unarguable that there is Something Going On with XML and
natural languages.  I don't really feel up to defining this precisely
just now, but I think most people here know what I mean.  I think that
the connection between an XML namespace and natural languages is the
main reason we went to so much trouble to accommodate Unicode in
markup.  I now realize that we will have to deal with linguistic
communities right up front in the process area as well.

When you boil it right down, I believe that OASIS is mainly going to
be a brand name for a process -- the process that we're designing.
For that process to have real existence for users of a linguistic
group, it has to be available in their language.  So this means either

(a) That we arrange to have Robert's (all 706 pages) translated into,
    say, twelve different languages, or

(b) That we specify a simpler process description of our own
    composition and have that translated into twelve different
    languages.

I wish there were a third choice

(c) That we use an existing committee process of the United Nations
    that's already translated into twelve languages

and in fact there might be such a thing, but after poking around
what's visible on the web, I have a feeling that a generic
U.N. committee process wouldn't fit a technical committee very well.

(I would really like to be wrong about this, so if someone knows
differently, please speak up.  If no one has any information at all on
this subject, I shall be forced to spend an afternoon in the
government stacks at the UC Berkeley law library, which actually would
be not all that bad a way to spend an afternoon if I had one, but
under the circumstances would be quite an inconvenience if it didn't
have to be done.)

The fallback to Robert's was pleasing to me because of its detail and
general availability.  But if we're really playing multilingual here,
that won't work.

I don't think that failing to provide a detailed process or allowing
different processes within different linguistic communities are
acceptable answers for an organization whose chief reason for being
seems to me to be the provision and maintenance of uniform processes.

Consider a company in Hong Kong that does web design; it should be
able to allocate a bilingual person on a half-time basis to
participate in both the OASIS TC for the design of an XML data format
for restaurants in Hong Kong, holding its discussions in Chinese and
using Chinese for the specification and the tag and attribute names,
and an international OASIS TC designing a common office document
format and transacting its business in English, using English tag and
attribute names.  Such a person should not have to learn two separate
sets of committee procedures to participate in these two TCs if they
are both OASIS TCs.

If participating in OASIS work means anything, it means this, yes?  If
I am wrong about this, I need to know.

To me (I told the groups I spoke to in Japan), OASIS means a stable
and well-understood process meeting the following criteria:

   Careful, open, and fair

   Low cost of entry

   Represents all the stakeholders in a user community

   Uses a democratic process

   Allows real differences to be resolved

   Creates intellectual property that is owned by everyone in
   the community

   Allows time to test implementations

   Provides a framework for distribution and acceptance

OK, so this is just marketing and probably needs some tuning.  But a
lot of this boils down to establishing a level of civility that I find
missing from some standards work and that I think my audiences have
missed in dealing with international standardization efforts even more
than I have.  (Some of these things are pretty darned basic.  "...any
matter on which there is a difference of opinion among the Lords is to
be put to the Question; and if the Lord Chancellor will speak to any
thing particularly, he is to go to his own place as a Peer."  Basic
Robert's, and here's where it probably comes from: House of Lords
Standing Order 16, passed 27 March 1621 and unchanged as of the
edition of 1994 (London, HMSO).)

Following is a description of the way it sorts out for me at this
point.  Tell me what you think.

1. We must provide rules for committees to ensure orderly
   consideration and fair treatment of all interested parties.
   This means [for example]:

   a. Allow all points of view to be heard, but also allow the
      committee to limit its own debate and move on.

   b. Don't put a lot of wrenching decisions on the chair.
      Provide ways to make the committee as a whole take
      responsibility.

   c. [I don't have language for this but I'd sure like to see
      the Quaker Poll instituted somehow.]

   d. [Insert here a list of other basic principles of
      organization distilled from various works on committee
      procedure]

2. Since we're designing process from scratch, the committee
   rules might as well be optimized for the construction of XML
   language definitions and might as well deal with how business
   is to be conducted by email.

3. However, the normal procedure should be based as closely as
   possible upon accepted parliamentary models like Robert's.

   (I am seriously entertaining the idea of copying pieces
   verbatim from the 1915 edition.  It's less than half the size
   of the current edition and, being the last edition written by
   Robert himself, it reads better.  See

      http://www.constitution.org/rror/rror--00.htm

   among versions available online.)

   There are not only good reasons to follow established practice
   in this area; it is also the least painful way to allow people
   who have gotten their idea of committee procedure from our TC
   rules to function at the level of the OASIS membership, which
   conducts its business in English according to Robert's.  The
   goal should be that no one used to Robert's should be
   surprised by the TC rules and vice versa.

4. A choice of major languages should be available to all
   designers and users of an XML specification.  This means that
   the process description must be small enough to translated
   (presumably by translation committees formed for this
   purpose).  We want small but detailed enough to keep people on
   track.  Maybe OASIS can do for Robert's what XML did for 8879.

5. I suggest the term "language of reference" to designate any
   of the set of languages recognized by OASIS for the creation
   of OASIS technical specifications.  Since OASIS is a
   Pennsylvania non-profit corporation that conducts its business
   in English, the bootstrap language of reference is English.  A
   recognized language of reference is simply one into which the
   Rules of Order for OASIS Committees has been translated.  The
   OASIS board (or maybe the whole membership) decides when a
   language of reference has been established by a satisfactory
   translation and determines that resources are available to
   maintain a minimum level of support for the foreseeable
   future.

   Translation is hard, but if the process itself is well
   designed (i.e., based on models known to work) then
   translation needs to be done rarely.  The cost of translation
   will tend to discourage frequent modification of the process,
   which is probably a good thing.  Translation doesn't need to
   be done right away, which is a very good thing.  We could
   probably get along for a couple of years on just English,
   Japanese, and Chinese, and I'm fairly confident that we can
   get someone to do the first two translations if we keep the
   size down and run some committees under the English version
   for a year or so to debug it first.

6. I see no immediately evident harm in continuing to allow
   votes on approving OASIS standardization to be votes of the
   whole membership for specifications written in even the most
   obscure language of reference as long as (a) the membership
   has approved the establishment of that language of reference
   and (b) the rules are constructed in such a way as to allow a
   relatively low number of votes for approval.  This last part
   can be tricky, and I'm not quite sure how to proceed with it.
   This becomes part of the whole question of how to approve
   OASIS standards, which I suggest that we consider separately
   from the question of whether we have to write our own
   committee process.

Jon