Re: Issue 231 options

Ray, thanks for your comments. Please see my few replies inside.
I've only kept the bits I'm replying to below.


On Thu, 2002-09-05 at 19:46, Ray Whitmer wrote:
> 
> Jacek Kopecky wrote:
> 
> > Hi all, 8-)
> > this email is meant as a summary of the options we have for resolving
> >LC Issue 231 [1].
> >  
> >
> Thanks.  Below are my own point of view on these alternatives.
> 
> > 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
> >           same.
> >  
> >
> I believe this is my preferred option.  This is based upon my belief 
> that it is impossible to reliably interpret messages or even bring them 
> in and out of the data model without some sort of schema describing 
> them.  There are plenty of types beyond arrays for which this is true. 
>  The call itself cannot even begin to be properly interpreted -- despite 
> efforts to identify the return.  Those who do not believe this probably 
> should not accept this answser.

In this case it would be very weird if we didn't provide the schema
language we implicitly or explicitly relied on. And I can also see a
schema language that is just a set of rules on the mapping from an XML
Schema schema to a SOAP Data Model schema and back. That would help WSDL
the most.

> > 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)
> >
> It should be permitted by the serializer, but not required of the 
> serializer, as I think was the original idea in SOAP.  Otherwise, the 
> SOAP spec has to change for other user-introduced types as well such as 
> simple types.

See my reply to Noah's email in this thread, basically I agree with
this.

> You could argue that there is currently a hole in that you cannot 
> distinguish between generics and structs, and the application might 
> erroneously ascribe importance to the order of the children when there 
> was none (or vice versa) if it chose the wrong representation.  This is 
> certainly not the only problem if you operate without a schema.

Again, see above for my comments about schemas. 8-)

> > 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.
> I think my use cases clearly need a schema language, as is reflected in 
> my implementation, but the serializers should be free to produce 
> self-describing where it is useful.

If we mandated self-describing data (in terms of the data structure
description) then a schema would be unnecessary in many cases on the
deserializer side.

> >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.
> >  
> >
> I might favor of removing generics.  We had one good use case for them, 
> the RPC call itself, as was pointed out in last-call comments, but that 
> is not on the table.  But I think there are those who may have good use 
> cases for them, and I think it is too late to pull them as long as we 
> get interoperable implementations to get us past CR phase.

My problem with generics is not only their redundance in the presence of
arrays and structs, it's also their unclear handling - are they
multistructs (no order between differently named accessor) or are they
arrays with named accessors or can they be either? Same problems here
with the deserializer giving importance to ordering when the serializer
just ordered it randomly.

Jacek

Received on Monday, 9 September 2002 16:27:35 UTC