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