wsdm message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: WSDM Call Minutes 5/18
- From: Heather Kreger <kreger@us.ibm.com>
- To: wsdm@lists.oasis-open.org
- Date: Thu, 18 May 2006 13:06:39 -0400
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]