RE: Comments on LC issues

Jacek,

> Therefore I ask - why do we need generic compound types?

I like using examples. Consider the following ordered list of labeled edges
in a directed edge labeled graph,

{a, b, c, a, a, d, b}

I request you to explain how a machine will encode this list of labeled
edges using one of your suggested techiques and decode this original list of
labeled edges:

- only arrays
- only struct
- array of struct

Please.

> implementation experience is that they don't fit nicely and
cleanly into an implementation of SOAP Encoding

This is bound to happen if you map SOAP data model to classes / struct and
arrays found in common programming languages.

I believe that the SOAP data model is a generalization of features found in
programming languages, databases and semi-structured data. And, generic
compound type is a sizable chunk in this mdoel.

Asir

-----Original Message-----
From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On
Behalf Of Jacek Kopecky
Sent: Wednesday, July 24, 2002 10:27 AM
To: Robert van Engelen
Cc: xml-dist-app@w3.org
Subject: 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, 31 July 2002 01:28:43 UTC