RE: Comments on LC issues

 Asir,
 I'm afraid I don't understand what graph you are representing by 
{a, b, c, a, a, d, b}. If the letters are distinct values, then 
this is an array. If the letters are names to, possibly different 
values, then the representation is
 <array>
  <x> <name>a</name> <value>value1</value> </x>
  <x> <name>b</name> <value>value2</value> </x>
  <x> <name>c</name> <value>value3</value> </x>
  <x> <name>a</name> <value>value4</value> </x>
  <x> <name>a</name> <value>value5</value> </x>
  <x> <name>d</name> <value>value6</value> </x>
  <x> <name>b</name> <value>value7</value> </x>
 </array>

 My reason for this? In SOAP Data Model, edge labels are used to 
distinguish the different outgoing edges of a compound value. As 
such, the names are not values that the application works with. 
On the other hand all the uses of generics I've seen so far take 
the names as values necessary for subsequent processing. In SOAP 
Data Model, values are nodes, not edges or edge labels. 

 Again, it depends on how a generic compound value's outbound 
edges are accessed, I've been suggesting different approaches but 
nobody said "this is how we do it".

 1) if the access is first by position, then choose action 
depending on the name, it is the case of Asir's example above; 
the name is a value and the representation should be an array of 
structs.

 2) if the access is first by name and then by position (e.g. the 
second 'a'), then the representation showing the nature of such 
data is a struct of arrays:
  <struct>
    <a arraySize="*">
      <value>first a</value>
      <value>second a</value>
    </a>
    ...
  </struct>
 In this the relative order of the distinct 'a's and 'b's is lost 
but because of the access pattern, this order does not matter 
anyway.

 3) If the sender and the receiver need not agree on the access 
pattern, then again the edge label is a value (may be a value) 
and therefore we get back to case 1).

 Please show me how generics are used differently from the three
patterns above.

 I know the charter says we should produce "a generalization of
features found in programming languages, databases and
semi-structured data" but I don't believe a generalization must
be a union of all components. SOAP Data Model without generics
can IMHO be used to represent to represent common data structures
from programming languages and databases. It is not meant to
represent every data structure efficiently in XML (see
associative arrays/maps), it is meant to be simple, mainly for
RPC.

 As for semi-structured data - can you define what it means? I
can't, therefore I can't argue what is the natural representation
for such data and whether generics are necessary here.

 Best regards,


                   Jacek Kopecky

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



On Wed, 31 Jul 2002, Asir S Vedamuthu wrote:

 > 
 > 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 Thursday, 1 August 2002 07:00:47 UTC