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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

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


Subject: FW: Proposed CGMOpen submission to W3C [private]




-----Original Message-----
From: James Bryce Clark [mailto:jamie.clark@oasis-open.org]
Sent: Tuesday, August 09, 2005 8:03 AM
To: Cruikshank, David W; lofton@rockynet.com
Cc: mary.mcrae@oasis-open.org; patrick.gannon@oasis-open.org
Subject: Proposed CGMOpen submission to W3C [private]


      As we've discussed, OASIS staff will need to reply to the concerns 
expressed by our Board of Directors when we brought forward your request at 
the July Board meeting in Billerica.   Your review of the issues below will
be helpful to us, as will any improvements you can suggest to the 
justifications and explanations.  .
      These are my drafting comments and questions, not a position of the 
organization.  Once we have your reactions, Mary and I will draft and 
submit a revised recommendation to Patrick.  In any case, we plan to 
re-present the issue to our Board at its next meeting.  This message is not 
the form of that report:  I am going into much more detail here, and being 
somewhat more candid, than I would recommend in a Board report or public 
document.  Thus I've addressed this message to you personally here, rather 
than via the archived lists.

       While I recognize that there have been obstacles here, we've tried 
to be clear that the TC's request is unusual for OASIS, not a routine 
procedure.   Under our Liaison Policy we usually only  grant permission to 
send specifications to other organizations *after* they've been adopted as 
OASIS Standards.  The reason for this isn't insularity, but rather, an 
attempt to serve two of our policy goals.
      One is quality control:  the various elements of our process 
(review  periods. public notice, approval votes, etc.) are designed to 
ensure some attention to content quality, specifically above and beyond the 
work of the spec editors themselves.   "Process" and public review time is 
an irreducible feature of any legitimate standards process:  I'm sure it 
can be frustrating, but no matter how cohesive and certain a working 
group's core members, we can't abridge it.
      The other goal is convergence:  much of our liaison activity is 
designed to optimize successful cooperation by multiple organizations on a 
specification.  I don't fault our Board for asking closely whether there's 
a risk of divergence here that would cause confusion.  We need to have a 
compelling response.

      There are three questions we will need to address.

      1.  Will the plan lead to two different WebCGM specifications?
      2.  Will the plan create IPR availability problems?
      3.  Why can't W3C submission wait until after the OASIS process is over?

I'd appreciate any additions or corrections to each of these.

      1.  Will the plan lead to two different WebCGM specifications?

      As I understand it, the WebCGM TC plans (a) to bring the adopted 
OASIS Committee Specification v2.0 to W3C, so all new ideas would be "baked 
in"  at that stage, and then (b) to collect any comments or diff from the W3C
process and have submitted those back to the OASIS TC -- requiring a second 
15 day public review and then re-approval as a CS -- before putting the 
result up for member vote as an OASIS Standard.
      if that's correct, then the risk of two diverging specs comes only if 
W3C changes are either not contributed back to, or not accepted by, 
the  OASIS TC.  The first risk is addressed under #2 below.   The second is 
within the control of the TC.  Normally, our submission methods prevent 
divergence by agreement, not voluntary nonbinding preference of the TC 
members, so in this case it would be helpful to have some statement of the 
TC members' intent.  Can we report to our Board that the OASIS TC members 
intend to approve and include (as amendments to the final OASIS work) any
changes that are made and agreed over at W3?

      2.  Will the plan create license rule or availability problems?

      There are three possible issues here. One is whether the presence of 
the two (presumably identical) specs are hosted in two organizations would, 
somehow, interfere with each other's licensing availability to end 
users.  I can't see why that is a risk:   the work has no claims against 
it.  But let's one was made later.  Even then, a user's ability to acquire 
any licenses from claimants under the rules of one org should complement, 
but not interfere with, its rights to obtain a license from the same 
claimants under the other set of rules.
     The second issue is having the two sets of licensing conditions 
adequately similar that the two groups would, in fact, take in each other's 
work.  You mentioned that this might be a concern for W3C, and base on some 
prior behaviors, I agree.  In order to secure this, as we discussed by 
phone last week, the OASIS CGMOpen WebCGM TC should bring itself under the 
new OASIS IPR Policy and its "RF on Limited Terms" Mode.  This occurs under 
the IPR Transition Policy at 
http://www.oasis-open.org/who/ipr/ipr_transition_policy.php.  Please take a 
quick look at that policy, the timeline for which is a TC vote to convert, 
followed by a two week unanimous ballot and a two week transition period, 
at the end of which members who have signed the 2005 form of Membership 
Agreement (and only those members) are able to  participate.
      The third, and most serious issue, is the risk of disjunct 
contributions.  Both OASIS and W3C require that contributions come into 
their work via appropriate channels that conform to their respective IPR 
policies.  So, if (as in  Q#1 above) a set of W3C comments were 
incorporated into the work when submitted there, those same comments would 
need to be contributed back into OASIS, in order for the work to be 
"re-synced" by being approved with changes.  But that contribution might be 
troublesome if the W3C commenters were not OASIS members.  The risk is that 
some change comes into the work at W3 that is not then recontributed over 
to OASIS as well (via an OASIS member or a public comment 'feedback 
license').  In that event, the OASIS TC would not be able to admit the 
work, which would leave the two approved versions out of sync (and the 
earlier OASIS version obsoleted).   Can you shed any light
on whether this can be avoided?

      3.   Why can't W3C approval wait until after the OASIS process is over?

      Frankly, the toughest question we face with our Board is why the 
usual approach -- finish the OASIS Standard first, and then submit 
elsewhere -- will not meet your needs.  In our chat last week your reaction 
was, essentially, "because W3C won't do that, for branding reasons".  The 
difficulty with this answer is that it's essentially asking us to send what
is technically an incomplete work out early to solve another org's 
"branding" issues.   You'd indicated that about half your adopter base 
would like to see a W3C recommendation as well as, or instead of, an OASIS 
Standard.   I would love to find a plausible method of cooperative 
work.  But to our Board, this may not look like cooperation, if it's a 
unilateral transmission prior to final approval, with no guarantee that 
they'll sync back up at the end, because OASIS waives its rules to permit 
this but W3C doesn't.

      Please understand, it's fairly difficult for me to explain to the 
OASIS Board of Directors why we should take the position that OASIS 
Standard approval isn't good enough for a project.  If you can provide more 
information either about what W3C has indicated it's willing to do in this 
special case, or why the particular value proposition for WebCGM makes W3C 
action essential, so as to justify unilateral waivers on our part, that 
would be helpful ammunition for our return to our Board.

      I know your group would like to see joint action on your terms and 
your schedule.  However, to some extent, standards groups are specifically 
*about* imposing outside controls -- getting that imprimatur often slows 
down, tests or thwarts an apparent consensus, until the last process T's 
are crossed and I's are dotted.   I am sorry that we haven't yet been able 
to define a plan for genuine cooperation across the orgs that seems to work 
easily under both rulesets.  We appreciate your willingness to work with us 
to see if such a method can be found.

      Regards  Jamie

~   James Bryce Clark
~   Director, Standards Development, OASIS
~   jamie.clark@oasis-open.org



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