- From: Savas Parastatidis <Savas.Parastatidis@newcastle.ac.uk>
- Date: Thu, 3 Jul 2003 10:59:58 +0100
- To: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>, <public-ws-desc-state@w3.org>
> "Savas Parastatidis" <Savas.Parastatidis@newcastle.ac.uk> writes: > > You're right! My mistake. I don't see the problem with defining > > soap:attribute, though. Operations are binding specific already. Why not > > attributes? > > Operations are not binding specific. > What I mean is that we already have to define how wsdl:operation maps to a particular binding (through the WSDL to * bindings). That should be the case with wsdl:attribute. > > > > I see this as very restrictive. All you are doing is effectively > > defining in the WSDL specification a transformation from WSDL to WSDL. > > You are not making attributes a first-class WSDL element. > > Its as first-class as attributes are in OMG IDL. I believe that will > satisfy the needs of Grid and others who are interested in attributes. > No it wouldn't be first-class because I could define an interface with operations of the form <wsdl:operation name="getFoo"> ... and although the element wsdl:attribute was never used, I would still be interoperable. > This is the JavaBeans approach. When JavaBeans were being done there > was resistence to changing the language and so it was layered on. A > few years later, C# went ahead and made them part of the language. I > believe the C# model is better as there is no confusion about what's > a component and what's just a class. If you are familiar with Apache > SOAP or Apache Axis you'll know the endless user confusion about > why certain classes are not beans .. most people don't really > understand the difference. > > Here we are faced with the same choice. My answer is that we should > do what C# has done and make them part of the language. > Oh, I agree that they should be part of the language. But I think that what you are suggesting does not make them part of the language, just a hint for WSDL to WSDL transformers. > > What you are suggesting is similar to saying in IDL that the > > "attribute" IDL keyword suggests that every IDL-defined interface should > > have get/set methods. However, that is not the case. > > The semantic is that it is *as if*\ it has those methods. That means > that a request to get the value of that attribute would be by > invoking a get method etc.. As Jeff explained that's the OMG IDL > model and I believe that's what we should do too. I disagree with the above. The semantic is that _appropriate_accessors_ must be defined. Nowhere in IDL it is suggested what form those accessors will take. In the IDL to Java mapping those accessors take the form of getFoo(), setFoo() methods. In IDL to C# could take the form of C# properties. In IDL to savasLanguage may take the form of attributeFoo(out), attributeFoo(in) operations. If you want to make attributes first-class language elements, I believe you should allow them to appear in the language and define appropriate bindings, as it is the case with operations. However, we agree that attributes should be defined, so carrying on with this argument may not be productive. Perhaps, I should wait until something written is presented and then start this again :-) (That's a threat :-) .savas.
Received on Thursday, 3 July 2003 06:31:40 UTC