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

Re: Comments on LC issues

From: Robert van Engelen <engelen@cs.fsu.edu>
Date: Mon, 22 Jul 2002 22:02:42 -0400 (EDT)
Message-Id: <200207230202.g6N22gE10398@diablo.cs.fsu.edu>
To: xml-dist-app@w3.org

Dear Noah Mendelsohn and WG,

Thank you for allowing us to send an updated copy of our notes with
the proper annotations referring to our "earlier messages". We hope
that our comments and suggestions will be helpful for the difficult
task that lies ahead for the WG.

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. It is our opinion that the SOAP RPC return value accessor is ambiguous
   and imposes unnecessary processing complexities. For details on this
   issue, please refer to [1].

2. Section 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. Details can be found in [1].

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.

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

Thanks and 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 22:02:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:20 UTC