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


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.

regards, Frederick

Frederick Hirsch
Nokia


On Jun 28, 2007, at 8:12 PM, ext 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 in his message referenced at http://www.oasis-open.org/apps/org/ 
> workgroup/ws-sx/email/archives/200706/msg00065.html suggested the  
> following "plan":
>> So in the interest of being specific, I propose we do the following.
>>
>> 1. Continue to report and fix problems in the examples doc based  
>> on inspection or individual testing
>> 2. When there are no open issues, vote the document to CD
>> 3. Conduct a Public Review
>> 4. At the same time or afterwards, test each of the examples in  
>> some kind of virtual interop
>> 5. Drop any examples we cannot get sufficient testing of.
>> 6. Vote the document to Committee Spec.
>
> In general, this sounds like an excellent way to proceed. (minor  
> quibbles are that going to CD/Cs requires the vote of the TC, not  
> the issues list going to zero - but i understand and agree with the  
> intent that we should finish and test the work before approving the  
> spec :-) But Hal then goes on to say:
>
>> 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.
>>
>
> 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.
>
> I also agree that it is "a good thing" for the group to maintain a  
> list of work items (deliverables?) that it intends on doing. Hence  
> "clarifying" is not a bad thing. BUT, and this the important point,  
> it is not REQUIRED. And if it the attempt to modify the charter  
> fails, it doesn't mean the TC can't do the work anyway. (From a  
> process perspective, that's the problem with motions that don't  
> change the state of the world. If they fail, nothing has changed.)
>
> [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. An expansion of IPR scope  
> triggers what is essentially a re-starting from zero wrt IPR.  
> "Clarifying a charter by narrowing its scope, is also considered a  
> charter change, but since by definition, it decreases exposure,  
> there is no "re-start". The TC continues along doing less work. ]
>
> 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.)
>
> So in conclusion:
>
> I agree with Hal's proposed plan to move forward and believe the TC  
> can simply move forward on executing it. There is a draft document,  
> (working draft?). The TC can iterate on it, move it to CD status,  
> CS status, etc., when someone so moves and the TC concurs by the  
> appropriate votes.
>
>
> On Jun 27, 2007, at 10:56 AM, Greg Carpenter wrote:
>
>> WS-SX TC Minutes, June 27 2007
>>
>
> [ snip ]
>
>> ]
>>
>> 6. Continue discussion of SP examples document
>>
>> Chairs have contacted OASIS staff seeking guidance on whether a  
>> charter change is required to add the examples doc to the TC list  
>> of deliverables.  OASIS staff recommends a charter change due to  
>> the specificity of the deliverables in the existing charter.
>>
>>
>> Hal discussed his proposal, which can be found here: http:// 
>> www.oasis-open.org/apps/org/workgroup/ws-sx/email/archives/200706/ 
>> msg00065.html
>>
>> Tony:  Questioned whether a CS is appropriate for an examples  
>> document.
>>
>> Hal: Not set on CS but would definitely like a PR.
>>
>> Marc: Also question need for CS but support Hal's proposal of  
>> actively  testing  the examples.
>>
>> Prateek: Support Hal's proposal.  SP is special in that it has  
>> impact on application developers and administrators who set  
>> security policy as opposed to other specs which are implemented in  
>> the infrastructure.
>>
>> Chris K.:  Seems there is general support for Hal's proposal.   
>> Some TC members question  the need for PR and/or CS.
>>
>> TC agreed to  follow the usual TC process for advancing a TC  
>> document to a state consistent with the results of the pending  
>> charter revision ballot.
>>
>> AI: Hal will propose draft text for the charter change to the  
>> deliverables section.
>>
>
> cheers,
>   jeff
> --
> Jeff Mischkinsky			          		jeff.mischkinsky@oracle.com
> Director, Oracle Fusion Middleware and Web Services Standards	+1 
> (650)506-1975
> Consulting Member Technical Staff           			500 Oracle Parkway,  
> M/S 4OP9
> Oracle								Redwood Shores, CA 94065
>
>



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