Re: Comments on LC issues

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

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)?

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.

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.

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.

- Cheers, Robert

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

Received on Wednesday, 24 July 2002 23:10:54 UTC