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

Title: Message

I 
meant a charter scope change that impacts specifications.

 

  

  
-----Original Message-----
From: Anthony Nadalin 
  [mailto:] 
Sent: Friday, June 29, 2007 7:05 
  PM
To: Martin Chapman; 'Jeff Mischkinsky'
Cc: 'James Bryce 
  Clark'; 'Mary McRae'; ws-sx
Subject: Re: [ws-sx] WS-SX TC Minutes, 
  June 27 2007

  
Wow I think that you are confusing things. We make normative changes to 
  specs all the time without charter changes. 
-----------------
Sent from 
  my BlackBerry Handheld.

  
  
  
 ----- Original Message -----
  From: "Martin Chapman" 
  []
  Sent: 06/29/2007 11:51 
  AM
  To: Anthony Nadalin; "'Jeff Mischkinsky'" 
  <>
  Cc: "'James Bryce Clark'" 
  <>; "'Mary McRae'" 
  <>; 
  <>
  Subject: RE: [ws-sx] WS-SX 
  TC Minutes, June 27 2007

  
Changing to WS-Policy 1.5  was a normative change, examples 
  are not. If a TC can't produce supporting non-specification documents 
  

  
without a charter change then something is wrong.

  
 

  
Martin.

  
    

    
-----Original Message-----
From: Anthony 
    Nadalin [mailto:] 
Sent: Friday, June 29, 2007 
    5:47 AM
To: Jeff Mischkinsky
Cc: James Bryce Clark; Mary 
    McRae; 
Subject: Re: [ws-sx] WS-SX TC 
    Minutes, June 27 2007

    
hmmm, did we not just go though a charter change to add WS-Policy 1.5 
    ???? Seems odd that we would do it for that and not for this, since the 
    charter is specific on its scope and deliverables.

Anthony Nadalin | 
    Work 512.838.0085 | Cell 512.289.4122
" 
    src="gif00102.gif" width=16 border=0>Jeff Mischkinsky 
    <>

    
      
      

        
          
            
              
                Jeff Mischkinsky 
                  <> 
                  
                  
06/28/2007 07:12 PM

        
          
            
            

              

                
To

              


            

              

                
cc

              
James Bryce Clark <>, 
                Mary McRae <>

            

              

                
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 
              
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