W3C home > Mailing lists > Public > public-ws-policy@w3.org > October 2006

RE: NEW Issue [3894]: Definition of equivalence for WSDL 2.0 component model {policy} properties

From: Asir Vedamuthu <asirveda@microsoft.com>
Date: Mon, 30 Oct 2006 11:45:52 -0800
Message-ID: <1E0F0378382054439F14D5450650478F0B0578BA@RED-MSG-42.redmond.corp.microsoft.com>
To: Arthur Ryman <ryman@ca.ibm.com>, <public-ws-policy@w3.org>

+1

Thank you for sending out a concrete proposal. I request the WG to (accept and) assign this change to the editors.

Regards,
 
Asir S Vedamuthu
Microsoft Corporation




From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Arthur Ryman
Sent: Monday, October 30, 2006 11:26 AM
To: public-ws-policy@w3.org
Subject: NEW Issue [3894]: Definition of equivalence for WSDL 2.0 component model {policy} properties


I just opened a bug [2] on the following issue: 

Title: Definition of equivalence for WSDL 2.0 component model {policy} properties 

Description: The WSDL 2.0 Attachement Spec defines the {policy} property but does not define how to compare its values for equivalence. The spec is therefore incomplete. 

Justification:  Any WSDL 2.0 extension must define the meaning of equivalence since it is used in the definition of WSDL 2.0 component model validity. [1] If the spec does not define the meaning of {policy} equivalence then interop problems may arise, e.g. one implementation may produce WSDL 2.0 documents that another implementation regards as invalid. Furthermore, since WSDL 2.0 component models can be assembled from multiple documents which may contain repeated definitions of the same component, a clear test for equivalence is needed in order to detect any differences. These differences may be accidental errors introduced at authoring time, systematic errors injected at runtime, or malicious errors created by attackers. 

Target: This affects the WSDL 2.0 Attachment Specification. 

Proposal: The following text should be added to the WSDL 2.0 Attachment Specificationin Section 5.3 after Table 5-2 to make the definition of {policy} property value equivalence clear: 

Two {policy} properties are equivalent when they represent policies that contain the same number of policy alternatives, and each policy alternative in the first policy is equivalent to some policy alternative in the second policy, and conversely. 

Two policy alternatives are equivalent when each policy assertion in the first policy alternative is equivalent to some policy assertion in the second policy alternative, and conversely.  If either policy alternative contains multiple policy assertions of the same type, policy alternative equality is dependent on the semantics of that assertion type.

Two policy assertions are equivalent if they have the same QName and, if either policy assertion has a nested policy, both assertions must have a nested policy and the nested policies must be equal.  If either assertion contains policy assertion parameters, then the policy assertion parameters SHOULD be compared for equality.  Comparing policy assertion parameters for equality is not defined by this document, but policy assertion equality may be further refined by the corresponding policy assertion specification. 

[1] http://www.w3.org/TR/2006/CR-wsdl20-20060327/#compequiv 
[2] http://www.w3.org/Bugs/Public/show_bug.cgi?id=3894 

Arthur Ryman,
IBM Software Group, Rational Division

blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca
Received on Monday, 30 October 2006 19:46:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:42 GMT