Minutes
Agenda
Resolution: agenda approved
Resolution: minutes approved
AI review
Sanjay:
no open action items
new issues
Sanjay:
PaulF has a new issue
PaulF:
not sure if we need to deal with this
... but the issue concerns the references between our specs
references to WS-Policy from the WS-RX set
Sanjay:
on email it seems that there is consensus to reference both WS-Policy 1.2 (submission) and WS-Policy 1.5 CR
... perhaps editors can update us on what changes have been made
Dug:
I'd like Marc to describe his proposal; other changes are just fixing typos
Marc:
essentially it mentions that the WS-Policy version is for any verion of WS-Policy
... "at the time of this writing WSP 1.2 and WSP 1.5 are known to work"
Sanjay:
does anyone have any comments on the working drafts
Martin:
why aren't the references to WS-Policy normative?
Marc:
I believe that change was made in the last round of changes
... I don't recall proposing that change
Pete:
on previous calls there didn't seem to be any consensus that any version of WS-Policy was far enough along the stds process
to reference normatively
... WSP 1.2 is not a standard so it isn't a candidate
Sanjay:
I don't see any outstanding issues or comments
Gil:
I move to approve these specs as CD9
Anish:
just want to comment that the normative reference issue can be fixed in the next version
Pete:
can I ask Anish to explain that comment
Anish:
we're going to find errors and other eratta
... we can deal with the WS-Policy reference as an eratta
Martin:
I think that what Anish is saying is that once WS-Policy is a Rec, it would be appropriate to make it a normative reference
Resolution: These specs are approved as CD9; motion passes by unanimous consent
submission of 'CD9' for CS
Sanjay:
there are references between the specs in our set
... WS-RMP refers to WS-RM
... WS-MC refers to both WS-RM and WS-RMP
... these references are all to the CD versions of these specs
... there are OASIS rules that make updating these references problematic
... we can resolve this by indicating the fact that we intend to update the references
PaulC:
move what the chair just requested
<Sanjay>
Resolve that the "CD9 plus updates to the internal refs as CS instead CD" be submitted to the OASIS Admin for starting an
electronic ballot for CS approval/OS submission.
Marc:
the intent of that is that we know we have internal refs
... and that these refs need to be updated
... the WS-SX TC specs ended up having 'trailing refs'
Sanjay:
OASIS staff is aware of this problem and working on a proposal to fix this
Martin:
its very clear that the process does not allow changes to anything other than the cover pages and headers/footers
... this makes sense to us, but I think we should be more precise about what exactly is changing where
Sanjay:
if this motion passes, we can craft explicit text to be sent to Mary
PaulF:
no one has made a motion yet
Pete:
the OAIS document templates (and therefore our cover pages) contain a link to the 'latest versio' of the spec
... that's a dynamic link that updates on every new approval
Sanjay:
in the reference section we have description and a link
... linking to that latest version only solves the link problem, but the description would still be innaccurate
PaulF:
have you run this past the TC admin and OASIS?
Sanjay:
yes, the TC admin and OASIS staff knows we are going to do this
Dug:
I'm assuming we're going to do an atomic CS ballot, do we need an electronic ballot?
Sanjay:
the person that takes care of this at OASIS is out today, so the electronic ballot won't go out today
Dug:
I'm assuming we need to make a CS version, should the update include the CS version?
PaulF:
we do the updates after the vote for CS happens
<MChapman>
In WS-MC cd9 update the references to ws-RM and ws-rm policy to the CS versiona of those specs after WS-RM CD9 has been made
cd and before submitting to oasis standard.
Sanjay:
in the case that the current motion passes, I suggest we include the changes in the package that we send to the OASIS staff
Mr. Goodner I think this is fine
<Paul Fremantle>
For example
<Peter Niblett>
how far does this go?? You will need to update the footers as well
Sanjay:
I was hoping that there wold be explicit line numbers in the motion
<Peter Niblett>
ok fair point
<Paul Fremantle>
On line 396 of WSRMP the reference to WSRM Committee Draft should be replaced with the words Committee Spec
<Sanjay>
Resolve that the "CD9 plus updates to the mutual refs between WS-RM, WS-RMP and WS-MC specications as CS instead CD" be submitted
to the OASIS Admin for starting an electronic ballot for CS approval/OS submission.
Martin:
(moves to approve 3 specs as CS; the mutual refs in those specs be updated to the CS version)
<MChapman>
For the WS-RM, WS-RMP and WS-MC specification set, that the mutual refereces between specifications in this set be updated
to refer to the CS versions one approved and before submitting the set as OASIS standard
Anish:
mumble, muble CS version
Anish:
we need to do the same thing to the OS verions
All: (discussion about what happens at OS time)
PaulF:
the same rule applies between CS and OS
... "No changes can be made except on the title page and headers/footers"
<Paul Fremantle>
I had a generic fix
Matt:
this isn't the first time this came up
<Paul Fremantle>
which was to make the change in advance and vote on it
<Paul Fremantle>
but OASIS staff didn't like that
<Paul Fremantle>
which riled me
Resolution: For the WS-RM, WS-RMP and WS-MC specification set, that the mutual refereces between specifications in this set be updated
to refer to the CS versions one approved and before submitting the set as OASIS standard. motion passes by unanimous consent
Sanjay:
need to package up these specs and submit them to OASIS for a ballot to approve as CS
Martin:
moves to submit docs (after updates) to OASIS for a CS ballot
Gil who 2nd-ed?
Resolution: Submit these docs (after updates) to OASIS for a CS ballot. motion passes by unanimous consent
Anish:
moves to submit specification set for consideration as an OASIS Standard
Martin:
we still need 3 declarations of use
Pete:
also contingent on passing of the CS ballot
Martin:
but you can do them in parallel
PaulF:
WSO2's declaration of usage still applies
Matt:
IBM's declaration of use still applies
Sanjay:
SAP's declaration of use still applies
PaulF:
doesn't the wording need to be tweaked a little?
Sanjay:
do you have an ammendment
PaulF:
(add clause that says 'provided the CS passes')
Anish:
do you have specific text?
PaulF:
not right now . . .
Sanjay:
any other comments?
Resolution: To submit the specification set for consideration as an OASIS Standard. motion passes by unanimous consent
other business
Martin:
when will our next meeting be?
Sanjay:
electronic ballot won't close until late next thurs
Martin:
would there be any point in having that call if the CS ballot passes (and the subsequent OS ballot passes)
DougB:
need someone to backstop the WS-RX TC admin and get the vote up today
<Dug>
+1 to pushing Oasis to get it up today
<Mr. Goodner>
tc-admin@oasis-open.org for formal requests
Sanjay:
there is a backup person, but they need to review the material, etc.
... chairs will make sure the request is sent
Marc:
we've run into situations where, if that email address isn't used, OASIS claims they weren't properly notified
(discussion about what email lists to CC for material submission)
PaulC:
share Martins concern for a more concrete plan for a meeting
<Dug>
if we only have a 5 minute meeting I'd prefer to cancel it
... how long to I need to hold this 90 minute bloc on my calendar
<Paul Fremantle>
I propose that we cancel the meeting if both votes pass
... would like to give chair the option of cancelling the meeting if certain things occur
Martin:
if the ballots pass there is no need to have a meeting
Sanjay:
we will have a few days between the ballot closing and the meeting that will allow the chairs to decide whether or not to
cancel the call
<Paul Fremantle>
thanks sanjay!