OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

workprocess message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: PAC: Issue CS 6 (Language communities)


To: workprocess@lists.oasis-open.org
Subject: PAC: Issue CS 6 (Language communities)

A while ago I noted the connection between tag languages and
natural languages, and I raised the issue of how we allow
different language communities to operate under this process.

   http://xml.org/archives/workprocess/msg00220.html

I said then:

   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.

I still think that these suggestions are a good ones as far as
they go.

At the time I wrote the passages above, I believed that we would
have to write our own process rules from scratch and have those
rules translated into each "language of reference."  Now I think
that we can get away with writing a committee manual (which I
suspect we will have to do anyway) and point to Robert's as the
normative reference for the hard cases.  Then the procedure for
some language community not previously recognized by OASIS would
be:

   1. Form a translation committee (see issue CT 7) using the
      generic procedure for TCs.

   2. Translate the committee manual into the candidate language
      of reference.

   3. Approve the translation (details TBD).

   4. Approve the new language of reference.

   5. Allow TCs to be formed that use this language of reference,
      the normative process remaining the English version of
      Robert's.

The downside to this plan would be that someone would have to
write the committee manual.  This now looks a lot harder to do
than I thought it would be six months ago.  On the other hand, it
may be possible to automate the process; if that turns out to be
the case, then we could just localize the interface.  (Yes, I know
it's hard to localize an interface, but I think it's not as hard
as translating the process.)

The alternative (I think) is to allow the formation of
geographical divisions of OASIS and let each one define its own
process.  But then we have the problem of how to be sure that
approval of a specification meets the same criteria in one
language as in another.

Let's talk about this Thursday.

Jon




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC