Issue 231 options

 Hi all, 8-)
 this email is meant as a summary of the options we have for resolving
LC Issue 231 [1].

 Now the issue 231 is mainly about how the receiver distinguishes that
something is an array. We have the following options here:

        1. Doing nothing, relying on the receiver that it know what the
           incoming data really is (as most implementations do). In this
           case we should clarify whether array members' accessor names
           have to be the same or not. The spec currently says these
           names are irrelevant, so it seems like they need not be the
        2. Mandating arraySize (or itemType, but the former is
           preferable because it has a default value now) like SOAP 1.1
           mandated arrayType - that way a receiver will always know an
           array when it sees one.
        3. Mandating that array members' accessors all have the same
           name. This would unify arrays, structs and generics but then
           the array attributes would be sticking out; also the receiver
           would have to see the whole data to be able to differentiate
           between an array and a struct or a generic, and this
           distinction would still be impossible when the given compound
           type is empty.

 There is a related issue of distinguishing an empty compound type from
a simple type (like an empty string).

 I think this all boils down to two orthogonal questions that cover all
the issues above:

        A. Should SOAP Encoding serialization produce self-describing
           XML? (self-describing in terms of the data structure)
        B. What is the relationship of generics, structs and arrays?

 If the first answer is "no" then we may need a schema language to help
the deserializer (see for examply my message [2]) or we can rely on
external means, but that should be said explicitly.

 Now the second answer has (at least) two variants:

   a. there are compound types, some of them structs, some of them arrays, 
      all of them can be treated as generics
   b. there are compound types of three distinct kinds: structs, arrays and

 Because this is undecided, we have an issue about removing generics.
IMO the presence of array attributes (arraySize, itemType) indicates
that arrays and structs cannot be treated the same way, therefore
pointing to answer b) above. Anyway, answering question B affects how we
resolve all these issues.

 What do you think?

                   Jacek Kopecky

                   Senior Architect, Systinet Corporation


Received on Thursday, 5 September 2002 09:00:01 UTC