Issue: SOAP Data Model Schema language may be necessary (related to #231)

 Hi all, 8-)
 if replying please remove XMLP Comments list from the CC.

 Last Call issue #231 started in [1] by asking what was the
difference between a struct and an array when the array element
doesn't have any of the "arraySize" and "itemType" attributes.  
The truth is, it may be impossible to distinguish between an
array and a struct in this case.

 The issue then moved to asking whether all the array member EII 
names have to be the same - that's currently the issue #231.

 In [2] I replied to the person who originally asked (Kevin
Johnsrude) that his issue may not in fact matter because we
expect that the deserializer will have the data structure 
available so by following it the actual kind of the compound type 
will be apparent.

 Implementing the array encoding in Systinet WASP we have found 
that this is very true, that the data structure is indeed 
necessary to deserialize a serialized graph containing compound 
types.

 I feel therefore that as long as the data structure must be 
present when deserializing SOAP Encoding data, a language for 
capturing such data structure must be provided along with SOAP 
Encoding specification.

 The possible solutions I can see are two:

 1) remove the need for data structure when deserializing data - 
marking structs and arrays in an unambiguous way in the 
serialized instance (I'll elaborate on this below);
 2) or provide a language that represents SOAP Encoding schemata.

 The second solution would represent a significant body of work 
and it cannot be done without reissuing a Last Call for comments 
later.

 The first solution has little impact and should not necessitate 
reissuing LC.

 Possible implementations of marking of different kinds of 
compound types:

 a) mandating that the arraySize attribute be present on array
instances (making the default value explicit usually)
 b) adding an attribute on compounds that would mark their kind.

 The first possible implementation is very similar to SOAP 1.1's
solution and it is very simple to implement, but it doesn't
handle the other corner cases with an empty struct vs. a
primitive node; or a generic vs. a struct.

 The second possible implementation makes SOAP Encoding instances 
fully self-descriptive.

                   Jacek Kopecky

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


[1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jun/0125.html
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0028.html

Received on Monday, 15 July 2002 17:11:46 UTC