- From: Jeff Mischkinsky <jeff.mischkinsky@oracle.com>
- Date: Mon, 30 Jun 2003 18:49:33 -0700
- To: "Savas Parastatidis" <Savas.Parastatidis@newcastle.ac.uk>, "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>, <public-ws-desc-state@w3.org>
- Cc: "Steve Graham" <sggraham@us.ibm.com>
At 10:47 AM 6/30/2003, Savas Parastatidis wrote: > > > In IDL, if you say "attribute string foo" its simply another way > > of saying "string getFoo ()" and "void setFoo (string)". > > > >I think there is a misunderstanding here. In IDL, saying "attribute >string foo" DOES NOT mean "string getFoo()". The CORBA IDL binding to >JAVA says that. Actually it does, in a logical sense. The IDL says there will be a method/function/procedure in the target programming language that will have one output parameter that is that programming language's mapping of the type IDL string. And there will be another method/functionc/procedure in the target programming language that will have one input parameter whose type will be that programming language's mapping of the type IDL string. The actual name and signature is defined by the rules for the programming language. The language mapping designer's picked method/function/procedure names and types that seemed natural for the target programming language and which met the other rules language binding rules. E.g. the method/function/procedure name(s) had to be guaranteed not to collide with any other mapped name for user-defined IDL operation names or other names generated by the language mapping. >In IDL, when you say "attribute string foo" all you have suggested is >that there is an attribute called foo as part of the interface. And that there will be 2 methods, one of which gets the value of foo, and one of which allows for the setting of foo. What the implementations of those methods do, is completely upto the designer of the interface and the implementation code. I believe this discussion about stubs/skeletons is a complete red herring. If you are using DII, there are no stubs and skeletons, but the semantics are still the same -- none. The implementations of the getter/setter can do whatever they would like. There is no more (or less) requirement that in Java that void foo(int l) do anything particular, then void bar(int l) which was generated from IDL that looks like interface xface { void bar(long l); attribute long l}; (assuming i've got my idl syntactic details correct ;-) > The IDL >specification gives you the means to write interfaces that contain >attributes. which is just a shorthand for getter/setter IDL operations. In fact one is guaranteed better consistency in the language mappings by explicitly defining the getter/setter operations in IDL rather than using the attribute keyword. This is because the use of getter/setter IDL operations means the operation names follow the regular IDL name mapping rules, rather than the special ones which are defined for mapping attribute names. jeff > That is exactly what WSDL should do as well. > >In WSDL, saying > ><interface ...> > <attribute ...> >... ></interface> > >should only mean that there is an attribute as part of the interface. whatever that means. This is the tricky part: defining the semantics of what it means for something to be an attribute of a WSDL interface. If we were to follow the CORBA IDL model, it would be exactly equivalent to defining operations with the right signatures. jeff > > Without such an approach, there's no way to implement a stub > > so that it knows what to do when someone wants to read the attribute. > > > >How an implementation creates stubs from a WSDL interface should be >irrelevant to the WSDL specification. > > > WSDL as the IDL for Web services should presumably support the same > > model for attributes: an attribute x in WSDL means that the service > > offers getx() and maybe setx() (if the attr is readonly). > > > >Do you mean getx() and setx() WSDL operations? If that is the case, then >you don't need attributes. If you mean that there should be a way to >get/set the values of attributes, then yes... that's the responsibility >of the binding specification. In one of my previous messages I suggested >just that. > > > Are you now agreeing this is the right way to go? IIRC you disagreed > > earlier; my apologies if I misunderstood you. > > > >No, I have not changed my position. It's the same. I thought you agreed >with what I was saying. Sorry for the misunderstanding. > >.savas.
Received on Monday, 30 June 2003 22:18:10 UTC