Re: Issue 210: component equivalence

Mark Nottingham wrote:
> 
> I have an AI to start discussion of issue 210 with a straw-man proposal.
> 
> Section 2.15 of part 1 says:
> 
>>  Two components of the same type are considered equivalent if,  for 
>> each property, the value in the first component is the same  as the 
>> value in the second component.
> 
> 
> I propose replacing this with:
> 
> -->8--
> Two component instances of the same type are considered equivalent if, 
> for each property of the first component, there is a corresponding 
> property with an equivalent value on the second component, and the 
> second component has no additional properties.
> 
> Instances of properties of the same type are considered equivalent if 
> their values are equivalent. For string values, this means that they 
> contain the same sequence of Unicode characters. Values which are 
> references to other components are considered equivalent when they refer 
> to equivalent components (as determined above). Finally, et-based values 
                                                           ^^^
                                                           set-based

> are considered equivalent if they contain corresponding equivalent 
> values, without regard to order.
> 
> Extension properties which are not string values, references or sets of 
> strings or references MUST describe their values' equivalence rules.
> --8<--
> 
> For string equivalence, we might also consider referencing Unicode 
> technical note #5: <http://www.unicode.org/notes/tn5/>, as the text 
> above doesn't cover some scenarios.
> 
> Section 2.15 goes on to say:
> 
>>  With respect to top-level components (Interfaces, Bindings and  
>> Services) this effectively translates to name-based equivalence  given 
>> the constraints on names. That is, given two top-level  components of 
>> the same type, if their {name} properties have the  same value and 
>> their {target namespace} properties have the same  values then the two 
>> components are in fact, the same component.
> 
> 
> I don't know what to make of this, as it seems to contradict the 
> statement above it; we're first told that equivalence is determined 
> across all properties, and then just across {name} and {target 
> namespace} for an ill-defined subset. What was the intent here?

Given that different top-level components must have different names,
if you process a valid WSDL document and get some components out of it,
you can decide whether two top-level components are equivalent just
by comparing their {name} properties.

I agree that it's confusing as written, by the way.

Roberto

Received on Monday, 21 June 2004 19:56:58 UTC