wsdm message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: WSDM Agenda 5/25 - Must Have Quorum for a SHORT call!
- From: Heather Kreger <kreger@us.ibm.com>
- To: wsdm@lists.oasis-open.org
- Date: Thu, 25 May 2006 10:14:58 -0400
Hi all
Today we need to vote:
Tthe changes to MUWS 1 and 2 that Vaugh
has made as committee draft.
To submit to admin for committee spec
To submit for OASIS standard vote
So, we'll have a short call: Agenda:
1. Roll
2. Approve Committee Draft
3. Decide if should respond publicly
to comments
3. Vote to submit to admin to ballot
as a committee spec
4. Vote to submit for OASIS standard
vote
I've included the minutes from last
week to list the changes that we are voting on and the process before us:
Talk to you then,
Heather Kreger
STSM, Management Standards Architecture and Strategy
Standards, Software Group, IBM
Author of "Java and JMX: Building Manageable Systems"
kreger@us.ibm.com
919-543-3211 (t/l 441) cell:919-496-9572
----- Forwarded by Heather
Kreger/Raleigh/IBM on 05/25/2006 10:05 AM -----
Heather Kreger/Raleigh/IBM@IBMUS
05/18/2006 01:06 PM
|
To
| wsdm@lists.oasis-open.org
|
cc
|
|
Subject
| [wsdm] WSDM Call Minutes 5/18 |
|
First - We NEED QUORUM NEXT WEEK!
Now,
On our call today we discussed: 5/18
Process
- make changes
- respond to public-comment
- agree non-substantive (else have to do another public review)
- approve editorial changes - approve as CD
ON Next Call 5/25 we will
Motion to submit to admin for committee spec
Motion to submit for OASIS standard vote
- send Mary an email to start 2 ballots - Approve Committe Draft as Committee
Specification and submit for OASIS Standard ballot ending about June 1-
need 2/3 voting Yes. Ballots end June 1.
If both pass - send standards submission to Mary by June 15. (early
better so can get something fixed by 15th)
Changes approved: Make and post on Monday.
Motion to approve editorial changes - Fred/Richard
Relationship issue changes
1.change muws1:endpointReference to wsa:endpointReference in 1377
2.add wsaendpointRef after line 1175 with *
3.add description of the element in 4.1.2.2 after 1204
4.Fix example at 1254/56 and move up in sequence
5. Remove sentence starting 1218 and ending 1221 about MOWS refs
6. Remove "not manageable by itself,
but is " on 1227
7.change muws1:endpointReference to wsa:endpointReference in schema at
end of document 1765
8. change muws1:endpointReference to wsa:endpointReference in schema line
74
Sincererly,
Heather Kreger
STSM, Management Standards Architecture and Strategy
Standards, Software Group, IBM
Author of "Java and JMX: Building Manageable Systems"
kreger@us.ibm.com
919-543-3211 (t/l 441) cell:919-496-9572
"Wilson, Kirk D"
<Kirk.Wilson@ca.com>
05/15/2006 08:18 AM
|
To
| <wsdm@lists.oasis-open.org>
|
cc
|
|
Subject
| [wsdm] New public comment on MUWS Part
2 |
|
All,
This weekend I discovered a situation in MUWS Part 2 for which I just entered
a public comment (at Vaughn’s request). This email will include
both the public comment and some discussion regarding its resolutions:
Please note, I raise an entirely new (but related) issue in my comments
to the group.
The comment is: ********
In section 4.1.2.2 of MUWS Part 2, the sequence for the Participant child
includes (starting with line 1175):
<muws1:ManageabilityEndpointReference/> *
<muws1:ResourceId/> ?
. . .
{any} *
The explanation of the any makes reference to the MOWS defined EndpointReference
element for use when the participant is a Web Service (rather than a WSDM
resource). The example that accompanies this pseudo schema in fact
uses the mows:EndpointReference element (beginning line 1254).
However, in section 4.2.2, the sequence of Participant is presented as
(starting with line 1376)
<muws1:ManageabilityEndpointReference/> *
<muws1:EndpointReference/> *
<muws1:ResourceId/> ?
. . .
Now we have a muws1:EndpointReference inserted into the sequence. The
schema of MUWS Part 2, RelationshipParticipantType (beginning line 1760)
supports this sequence rather than the one in 4.1.2.2. Unfortunately,
there is no MUWS1 definition of EndpointReference.
*********
Comments to the group:
1. I
believe this was a problem with WSDM 1.0, since WSDM 1.0 didn’t define
a muws1:EndpointReference either.
2. The
most efficient solution appears to be to eliminate the muws1:EndpointReference
from both the pseudo schema in 4.2.2 and from the schema. Eliminating
it from the schema is a potential breaking change, but since there no such
thing as a muws1:EndpointReference, we wouldn’t be breaking anything that
is not already broken J.
3. A
deeper issue might be why are we using the mows:EnpointReference in the
4.1.2.2 rather than the wsa:EndpointReference. The MOWS EndpointReference
has special semantics within the MOWS Identification capability as the
Web Service being managed through MOWS. I don’t think there is that
kind of implication in this case—that the participant is a Web service
that is being managed by MOWS. But the change here would be more
substantial, since it would require reformulating the explanation of the
“any”. I did NOT include this issue as part of the public comment.
That should be a separate public comment. Since this is an
“any”, it kind-of covers the wsa:EndpointReference without the text explicitly
saying it does.
ANY THOUGHTS ON POINT #3?? Is this worth pursuing at the last minute?
(Decision required by the 18th.)
Kirk Wilson
CA Inc.
Architect, Development
Office of the CTO
Tele: + 1 603 823-7146
Fax: + 1 603 823-7148
<mailto:kirk.wilson@ca.com>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]