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


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]