W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2002

Re: Comments on LC issues

From: <noah_mendelsohn@us.ibm.com>
Date: Mon, 22 Jul 2002 20:22:28 -0400
To: Robert van Engelen <engelen@cs.fsu.edu>
Cc: xml-dist-app@w3.org
Message-ID: <OF4EC9BEB1.E3E959BD-ON85256BFF.00015F53@lotus.com>

Thank you for your comments and suggestions.  Speaking for myself, not the 
protocols WG,  I would find it very helpful if you could send an updated 
copy of your note with actual links to the "earlier messages" you mention. 
 As I'm sure you're aware, this WG deals with literally hundreds of 
messages each week, and having a link will help us to better understand 
your concerns.   FYI, the distApp archive is at [1].  Thank you!

[1] http://lists.w3.org/Archives/Public/xml-dist-app/

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







Robert van Engelen <engelen@cs.fsu.edu>
Sent by: xml-dist-app-request@w3.org
07/19/2002 04:00 PM

 
        To:     xml-dist-app@w3.org
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Comments on LC issues





These are the comments and suggestions by the "gSOAP project group" on the
LC working drafts of SOAP 1.2 specifications.

The comments below were carefully evaluated in our current gSOAP
prototype implementation of the SOAP 1.2 working drafts.

1. SOAP RPC return value accessor is ambiguous and imposes unnecessary
   processing complexities (as explained by us in an earlier message).

2. Section 3.1.5.3 in "SOAP 1.2 Adjuncts" forbids id and ref attribute
   information items to appear in the same element information item.
   It is our opinion that this constraint unnecessarily limits the
   object graph data model. The resulting admissible data model does
   not allow for "pointer chain" graphs (as explained by us in an
   earlier message).

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.


Best regards,

- Robert van Engelen, gSOAP project group.
  Dept. of Computer Science, FSU, 162LOV/471DSL
  Phone: (850)644-9661/645-0309, Fax: (850)644-0058
  Email: engelen@cs.fsu.edu, URL: http://www.cs.fsu.edu/~engelen
Received on Monday, 22 July 2002 20:23:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:10 GMT