Re: Comments on LC issues

 Robert,
 it is apparent that SOAP RPC is the main use of SOAP Data Model
(and SOAP Encoding). Although the Data Model is very versatile, 
noone really wants to use it, see for example the WSDL movement 
(mainly in WS-I) from rpc/encoded to document/literal, i.e. from 
remote procedure calls using a graph data model to just sending 
documents with XML in them.
 This is IMO not caused by any restrictions inherent in the Data 
Model but in the fact that everybody already knows XML but few 
seem to grasp how other data models serialized to XML could be an 
improvement.
 My point against generics in the data model is that it is
completely unnecessary and foreign to most programming languages
I know. Most languages have the notion of an array (an ordered
sequence, list) and a struct (bag of named objects). Array alone
are sufficient because you can map the names (known beforehand)  
to numbers and use those as indexes. Structs therefore are mostly
a syntactic sugar. Mostly, not quite, because type checking can
be done by assigning different types to the different members of
a struct; this usually cannot be done for array members before
runtime.
 So structs are very common. In XML, structs also bring 
decentralized extensibility - many parties can add members to a 
struct and if name conflicts don't arise (namespaces should help 
here), and if there are sensible rules about defaulting missing 
data and handling unknown data.
 A generic compound type, as defined by SOAP Data Model, feels to 
me like an array where each member has a name (type QName). An 
array of structs in disguise, isn't it? 8-)
 Sparse and partial arrays were removed from SOAP Encoding, being 
judged unnecessary for similar reasons. 
 Finally, SOAP Data Model defines position as total order of a 
type's outbound edges. Generics could be imaginably used three 
ways:
 1) accessing elements in order
 2) accessing elements by name
 3) accessing elements by order and name
 4) accessing elements by name and order
 For the first, arrays suffice. For the second, structs suffice. 
 For the third case, it is like getting the third element and
then doing something depending on its name. The name is then a
part of the application data and should go there; the solution
being an array of structs that was mentioned before.
 The fourth case would first select all elements by their name 
and then access this selection by position. But the position here 
differs from what SOAP Data Model defines, being a partial order.
 Other use for a generic compound type would be if the data was 
to be used as a struct *or* an array at the discretion of the 
receiver. I've never seen any such application. In any case, such 
application don't form a significant percentage and the same 
thing can done using only structs and arrays.
 Therefore I ask - why do we need generic compound types? My 
implementation experience is that they don't fit nicely and 
cleanly into an implementation of SOAP Encoding.
 Best regards,
 

                   Jacek Kopecky

                   Senior Architect, Systinet Corporation
                   http://www.systinet.com/



On Fri, 19 Jul 2002, Robert van Engelen wrote:

 > 3. To comment on the Editor's request for comments on "generics":
 > 
 >       It is our opinion that generics should be kept in the specification.
 >       Generics are useful mainly from a practical point of view because
 >       generics do not widen the gap between SOAP RPC and SOAP DOC/LIT
 >       data models. We believe that abolishing generics only widens this
 >       data modeling gap, thereby unnecessarily limiting the expressiveness
 >       of the data model of SOAP RPC.
 > 
 > 4. We do not oppose the array representation of SOAP RPC invocation.
 >    However, we do strongly suggest the use of generic types to support
 >    both struct and array parameter paradigms. In fact, it is our
 >    opinion that generics should be the ONLY parameter marshalling type.
 >    In that way, polymorphic remote methods and remote methods with
 >    variable number of parameters can be supported, while providing a
 >    similar functionality as parameter marshallings based on structs
 >    and arrays.

Received on Wednesday, 24 July 2002 10:27:17 UTC