Re: Comments on LC issues

Well put Jacek. I completely agree with all these arguments. I find no 
place for Generics and have always found that any complex datatype can 
be expressed by a combination of structs and arrays. Only the basic 
building blocks should be provided from which all other types can be built.


Jacek Kopecky wrote:

> 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 
> 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
> 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 
> 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
>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 20:35:22 UTC