Re: Comments on LC issues

I see it differently. Soap-enc's purpose is to provide "common" data 
types that are available in "most" programming languages. For datatypes 
that are not available to soap-enc directly, it should be possible to 
combine the types that are available to produce the missing types. 
Generics are not "common" to most programming languages. They may be 
mapped to some aspects of more complex languages (such as structs in C 
that use pointers perhaps) but these types can also be represented by 
combinations of structs and arrays.

For Soap 1.1 some toolkits implemented Generics, others did not. Some 
that implement it have to hash it together using structs and arrays 
because their languages do not have the concept of Generic. I don't 
think soap-enc should be defining types that cannot be represented by 
common programming languages directly. Arrays and Structs are common 
language constructs - common enough that you expect them in almost any 
language.

Robert van Engelen wrote:

>Hi,
>
>I see two opposing forces pulling SOAP RPC either way: make it as
>simple as possible within reasonable constraints, which is good for
>interoperablility and 'light weightedness'. On the other hand, a limited
>model will derail potential use of SOAP RPC in more complex cases
>that can be handled without adding too much complexity to the SOAP RPC
>encoding style. IMO, SOAP RPC might be extinct before we see any
>real use of it, because users may hitch on to DOC/LIT's expressiveness.
>Let me play the devil's advocate here and add that SOAP is not that
>useful anymore if all it is used for is to envelope XML in a 'tidy'
>message for document exchange. I can do that much easier just over HTTP,
>and REST my case...
>

And you think removing Generics is all it will take for soap-enc to fall 
away? What is this based on when I have yet to see a use for generics in 
any real application (or interop test). You'd think if they were so 
important that they might be a little more common in the wild?

>
>I am not advocating to enhance SOAP RPC beyond a reasonable level,
>but I believe that SOAP RPC should be somewhere in between DOC/LIT
>and the data types commonly found in programming languages. For sake
>of argument, why would xsd:base64Binary be part of SOAP RPC if
>we have arrays (of bytes)?
>

There has to be some level of compromise where a type is required that 
makes common use practical. The size of a message becomes unwieldy for 
byte[] and base64Binary addresses that problem. This is a practicality.

>
>I do agree that generics are not orthogonal to structs and arrays,
>which is your basic concern. However, if SOAP RPC is to 'compete'
>as a viable alternative to DOC/LIT, we do want to keep it in the spec.
>

Again I don't see how this can be true when almost no-one has used them 
up to now. Because they don't map to common languages, there is little 
reason for soap toolkits in those languages to want to implement support 
for them (and any support will not be a natural part of the language, 
but an awkward wrapper type).


>
>To put this into perspective, the struct/arrays SOAP RPC parameter
>encoding is an illustrative example where the SOLE use of generics
>is an appropriate place. Variable parameter lists are very poorly
>represented and handled by arrays. In most cases, the array
>has to be an array of xsd:anyType to enable variable parameter list
>that contain parameters of different types. Does this simplify
>SOAP RPC processing? Generics are natural in this case. Please
>dare to see the horizon beyond implementation details that obscure
>our view.
>

I think this is a separate argument about whether there should be both a 
struct and array representation of parameter lists. It's lost on me to 
be honest. I would like to see the array representation dropped since, 
with any other RPC mechanism I have used, parameters are named (and when 
defining a service in WSDL you name the parts of the request/response).

>
>To demonstrate 'real-world' uses of generics in contemporary
>programming languages, consider the typical example of a struct
>in C with a pointer field to a dynamic array: it IS a (limited)
>generic. Sure, this can be represented as a struct with an embedded
>array, but the essence is lost in the transformation.
>

In what sense lost? You can reconstruct the data type from the wire 
encoding if it uses struct/array so what is lost? It may not be as 
natural as you would like, but I'm sure there are many examples 
(especially with pointers involved) where you could come up with even 
more cases where soap-enc (including generics) would not be sufficient 
not to "lose the essence" in the transformation. As long as the 
transformation is there that allows reconstructing a type then the 
representation is sufficient.

Pete

Received on Wednesday, 24 July 2002 23:37:05 UTC