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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-sx message

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


Subject: Re: [ws-sx] WS-SX TC Minutes, June 27 2007


   OASIS staff response below.

Frederick Hirsch wrote:
> I agree that I'm not convinced a charter clarification is needed
> to develop additional informational examples that could have been
> included in the specification.
>
> Jeff Mischkinsky wrote:
>> Hi, I'm writing this email because I'm a bit puzzled by some of
>> the statements/claims being made about the way forward on how to 
>> address the Examples work. * * * 
>>
>>>  [Hal] 6. Vote the document to Committee Spec.
>>
>> [Jeff] In general, this sounds like an excellent way to proceed. 
>> * * * But Hal then goes on to say:
>> 
>>>  [Hal] I guess I have to concede that this requires a charter
>>>  change, but I believe it is worth doing if we really want
>>>  people to be able to use WS-SP.
>>
>> [Jeff] I have to admit i don't understand why this requires a
>> charter change. Let me outline my reasoning. Certainly the TC
>> could have put in as much explanatory text as it wishes within in
>> the specification. It could have added (for example) chapters
>> 32-38 containing examples, rationale, pictures, etc. which help
>> to explain and make clear how to use the specification. So
>> clearly this kind of work is already within the scope of the TC
>> purview. We leave packaging issues  (how many files, format,
>> etc.) up to the editors and the TC (within the constraints set by
>> the general OASIS Process) to decide as they see fit, based upon
>> their determination of the best way to expose the TC's work to
>> the public.
>> 
>> I also have a hard time buying the argument that adding something
>> the charter constitutes a narrowing or lessening of the scope.
>> (Seems like an obvious contradiction.) * * *  To my way of thinking 
>> that are the only two reasons that REQUIRE a charter change -- to 
>> narrow the scope or to expand the scope. This proposal does neither 
>> of the two.
>> 
>> [A short digression on charter scopes. The reason OASIS tightened
>> up its Charter requirements was that with the new IPR policy, it
>> is necessary to provide companies with enough information to make
>> a reasonable determination as to the scope of the ipr commitment
>> they make when joining and participating. * * * ]
>> 
>> I note that the minutes from the meeting (pasted below) imply
>> that "OASIS staff" have said that a charter change is required.
>> Given the above reasoning and my reading of the rules, I'm
>> puzzled how they could have come to such a conclusion. I would
>> appreciate it if they could clarify, and explain their reasoning.
>> (i've cc'd jaime and mary on this mail.) * * *


   As staff, we are the first line of appeal under the OASIS TC 
Process rules. [1]  So we don't "rule" on a specific question before 
it is  officially raised.  In case it's helpful, here are some 
general observations.

   **  The rules don't mandate that every new project by a TC starts 
with a charter change, or even a pre-approval by the TC.  Subject to 
the important constraints below, any member can walk in with a new 
proposal, contribute it, ask for a vote, and have it approved as a 
committee draft, send it off for public review, etc.

   **  TCs can choose adopt procedural 'standing rules' or 
resolutions that constrain or sequence new projects. [2]  If so, 
then they must comply with them.

   **  The scope of a TC's charter absolutely limits what a TC can 
do.  If a new line of work is outside of that scope, it shouldn't be 
pursued in that TC, and won't be upheld as valid if appealed.

   **  Procedurally, if someone thinks that a TC's planned work 
would violate the TC's charter or standing rules, then once the TC 
has in fact acted (and only then), they can appeal that decision. 
First to staff ('TC Administrator'), then to our Board of Directors. 
  However, appeals are a rare, clunky, lengthy process that really 
ought only to be used if the TC fails to reach an appropriate 
decision first.

   **  For licensing purposes, please note, though, ultimately even 
our Board doesn't have the last word.  The reasons for this are 
legal and  technical, so I have noted them in a footnote below. [3]


   What may NOT be obvious, here, is the distinction between a 
charter's scope statement and its list of deliverables.

   **  OASIS has treated the deliverables list in a charter somewhat 
differently than the 'scope'.  Probably because, as Jeff mentioned, 
the scope clause is there to mark the limits of IPR obligations. 
Historically, some TCs had detailed deliverables, others didn't.

   **  As of 3 years ago, at the urging of several Board members, we 
started sharpening up the charter contents, to include a list of 
proposed deliverables in every charter. [4]  The Board also added a 
rule to make it easy to expand their list of deliverables, when 
consistent with the scope [5]; and a rule requiring staff to close a 
TC that has completed the deliverables listed in its Charter, if the 
TC doesn't add any more. [6]

   **  So to correct the statement made about advise from OASIS 
staff:  We encourage, but do not require, a TC to amend its charter to
update the list of deliverables and planned delivery dates.

   What seems under debate by WS-SX is whether elements in its 
charter that propose deliverable names, dates or specific 
configuration are a "scope" issue, like IPR, or a "deliverables" 
issue leaving the TC some leeway.   We note that other TCs have in 
the past re-factored their planned output, finding once underway 
that the contents of one spec actually fit better in two, or etc., 
without making charter changes. [7]  Initially this is for each TC 
to decide for itself.

Regards JBC

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

NOTES

[1]  Section 4:  http://www.oasis-open.org/committees/
process.php#board_involvement

[2]  Section 2.9:  http://www.oasis-open.org/committees/
process.php#2.9

[3]  Here's why.  If as a TC member I think the TC has jumped the 
fence, and is acting outside its scope, I still can take that 
position (Board or no Board) in any later legal dispute over 
licensing.  Then, if later asked for a license under the OASIS IPR 
Policy's minimum
'obligation' to license, I could assert that my duty only is to
give licenses in support of work completed by a TC within its
charter scope -- as I see it -- no matter what the Board thinks.  At 
that point, the question of what's inside or outside the charter 
could be settled by a court.  That court should be influenced by, 
but might not believe itself bound by, the interpretation that OASIS 
officially puts on the language of its policies or that TC's charter.

[4]  Section 2.2(1)(d):  http://www.oasis-open.org/committees/
process.php#2.2

[5]  Section 2.11:  http://www.oasis-open.org/committees/
process.php#2.11

[6]  Section 2.15:  http://www.oasis-open.org/committees/
process.php#2.15

[7]  However, of those that come to our mind immediately, none were 
appealed or resulted in formal rulings, and some occurred prior to 
the current set of rules.


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