RE: Property Composition Edge Cases

Thank you for the comment below, and for your patience with us in
resolving it.  We tracked the comment below as Issue LC27 [1].  The WG
agreed to change the property composition model so that required
properties trump non-required properties, instead of the previous
proximity rules.  The editors have addressed the issue in their latest
drafts [2].

If you agree with our disposition of your comment, we'd like you to
acknowledge it within two weeks; otherwise we will assume you are
satisfied.  The WG plans to enter a second (short) Last Call period in
the near future, and we invite you to review that publication as well.

[1] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC27
[2] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html
#Property_composition_model

> -----Original Message-----
> From: public-ws-desc-comments-request@w3.org [mailto:public-ws-desc-
> comments-request@w3.org] On Behalf Of Asir Vedamuthu
> Sent: Thursday, August 26, 2004 4:18 AM
> To: 'public-ws-desc-comments@w3.org'
> Subject: Property Composition Edge Cases
> 
> 
> ref:
> http://www.w3.org/TR/2004/WD-wsdl20-
> 20040803/#Property_composition_model
> 
> Does our property composition model capture all possible cases? I am
> not
> sure. Here is a sample edge case,
> 
> <interface name="Bank">
>     <!-- capable of accepting Kerberos v5 token -->
>     <property uri="http://example.com/secure-channel#tokenType">
>      <value>wsse:Kerberosv5TGT</value>
>     </property>
>     ..
> </interface>
> 
> <interface name="OpenBank" extends="Bank">
>     <!-- capable of accepting x509 certificate -->
>     <property uri="http://example.com/secure-channel#tokenType">
>      <value>wsse:X509v3</value>
>     </property>
>     ..
> </interface>
> 
> According to Interface Component,
> 
> "The set of Property components corresponding to the property element
> information items in [children], if any, plus the set of Property
> components
> in the {properties} property of the Interface components in {extended
> interfaces}, if any."
> 
> According to our equivalence rules, property declared in Bank
> interface is
> not equivalent to the property declared in Open Bank interface.
> Because, the
> value of {value} property is different. If these two property
> components are
> present in interface component.{properties}, what is the net effect?
> This
> will be further complicated if I use {value constraint}. Do we have a
> notion
> of type equivalence (for {value constraint})? Please revisit our
> property
> composition model and flush out all such edge cases.
> 
> Also, shall we provide a special rule for computing the equivalence of
> property components?
> 
> Regards,
> Asir S Vedamuthu
> asirv at webmethods dot com
> http://www.webmethods.com/

Received on Tuesday, 3 May 2005 19:58:12 UTC