OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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]