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.
Pete
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
>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.
>
>
>
>
>
>
>
>