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