- From: Pete Hendry <peter.hendry@capeclear.com>
- Date: Wed, 17 Apr 2002 00:13:40 +1200
- To: Jacek Kopecky <jacek@systinet.com>
- CC: xml-dist-app@w3.org
Now I'm confused :-( Comments inline. Jacek Kopecky wrote: >The second part of my proposal is more radical in that it >simplifies the model of a procedure by removing the in/out >parameters and return value terms. > This is the bit I don't understand. Here you say removing the return value term. From your original mail you say the same > 2) remove the term "return value" altogether: but... >Currently a message is able to say whether there is a return >value and what arguments are present (for the struct case) and >the spec is unclear (if not broken) for the array case. > Broken is also the term I would use. > > The first part of my proposed rewrite keeps it the same for the >struct case and makes it clear that there is no distinction >between a return value and an out parameter in the array case > ... but I must be reading this wrong. It seems to me that you were saying to remove the term "return value" which would also remove the use of the FQ name for the return value (you can't call it ...:return if you are not allowed to say it's the return value?) > >(because in my optinion there really *is no distinction* between >a return value and positional out parameters - they both don't >have a name and it doesn't really matter whether you start >counting the parameters from 0 or from 1). So effectively, this >first part of my proposal has no notion of a return value. > That's arrays only. The same logic does not apply to structs which use name instead of position. > > The full proposal goes further - removing in/out parameters >and the return value altogether. Now let me explain why I >don't think we're losing anything: > IMHO the notion of in/out parameters need not be in the protocol >since we don't have the explicit model of a procedure and a > > >in/out parameter in fact means one value going there and one >going back. When the parameter is named, they probably share the >name. In any case, only the language bindings are concerned with >this and we cannot help them here. Not every language supports >in/out params. > With return values it's a little more complex. It's already not >really there in the array case so let me only think about the >named parameters case. If we want a struct (as opposed to >multistructs which IMO would be dirtier to spec out) we have to >give a name to the return value. Currently we give it the full >name but many people complain this doesn't really play well with >XML Schema, which is true but which I don't think should concern >us at all. > This is what is confusing me. This paragraph and the following imply you are suggesting keeping the naming of the return value but the original mail, from my reading, was saying to remove the specific name. I must be misunderstanding one or the other. The following paragraph from the original mail is basically saying 'call the return value anything you want' is it not? > 3) add a note somewhere which says: "Note: many languages have >the notion of a return value - an unnamed [out] parameter. Such >can be dealt with by inventing a name like 'result' or using the >array serialization of RPC result. Also some languages have >[in/out] parameters which can be dealt with as couples of [in] >and [out] parameters in SOAP RPC. None of this affects >interoperability." > > There were proposals to only specify the local name (but the >possibility of various conflicts arises here which would have to >be solved in the language bindings). > There were proposals to keep the name in the application domain, >which is exactly what I've done in my full proposal. > So who defines this name? Is it defined by the person writing the service? How does my code generator know that this is the return value and give the generated method the signature intended by the service author? Does that not matter (does it matter if it is generated as a return value or an OUT parameter?). It think it IS important to be able to identify the intended return value. If for no other reason than consistency. I don't want to be on a project that requires clients in java and .NET (to pick but 2) and one generates a client with a return value and the other generates, from the same definition, a method with no return value and a single OUT parameter. > > I think either way (only first part or the full proposal) is an >improvement over the current state, with the second part only >going further in the direction of the first part. The first part >will not solve the issue 195, but that can be solved by saying >"we think mandating the full ns-qualified name is better than >only mandating the local name", please see my subsequent email on >this (it will have the subject "Issue 195: why not only specify >the local part" or something alike). > I have no argument with using a fully qualified name. I think that makes a lot of sense. I'm not actually sure what you are arguing any more putting these 2 mails together (I'm tired so maybe a reread of it tomorrow will help). Perhaps you could provide an example of what you mean for the java methods (i.e. what would the difference in their description or wire representation be?). void doSomething( OUT int value ) and int doSomething() I am coming at this from an implementor's point of view rather than the higher level that most will be looking at it from, and a fixed name makes a lot of sense to me. To this end I would agree that your term 'broken' describes the array representation case, and I am still struggling to see why there are 2 representations in the first place? Pete
Received on Tuesday, 16 April 2002 08:13:15 UTC