Title: Message
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="gif00093.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
