- From: Asir Vedamuthu <asirv@webmethods.com>
- Date: Thu, 26 Aug 2004 07:17:42 -0400
- To: "'public-ws-desc-comments@w3.org'" <public-ws-desc-comments@w3.org>
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 Thursday, 26 August 2004 11:17:45 UTC