Re: counterproposal on issue #144

On Tue, Nov 20, 2001 at 12:00:20PM +0100, Jacek Kopecky wrote:
>  Alan,
>  (the counterproposal is at the bottom of my text)
>  it is true that ordinary native arrays cannot usually hold three
> states. On the other hand you don't want to use an ordinary array
> for an array of billion nulls and 42 values so you use a
> different type anyway.

Agreed 100%. Which is why I am opposed to all arrays being p-t-a
without the possibility of a simple standard array type. To me
they are conceptually different types, and are best implemented
in programming languages by different types.

>  In WASP, we deserialize an array (any array) into Java array
> (putting nulls in the untransmitted positions) or our custom type
> representing a sparse array. Which is used depends on what the
> application expects and has in its interface.

Sounds completely reasonable - however it means that you have
lost semantics from the SOAP packet so an application cannot
tell the difference between a null value that has been sent
and an omitted value.

>  I also understand that sparse arrays can be represented as an
> other type, say an associative array (a map), which can be
> represented back as a fully transmitted array:
>  <sparseArray xsi:type="ns:Map">
>     <item><key>42</key><value>blah</value></item>
>     <item><key>123456</key><value>foo</value></item>
>  </sparseArray>

Exactly right. SOAP has the power to represent complex types.
Keep the simple types in SOAP simple, and use SOAP's ability
to capture complex types for complex types.

>  This would not be as efficient as native SOAP sparse array, but
> it would be a hell of a lot more efficient than a fully
> transmitted array. And the point about being (linearly) less
> efficient than SOAP sparse arrays is very weak in XML.

Again, agreed 100%. Its the point I have been trying to get
across all along.

>  It may be possible to delegate partially transmitted arrays
> (ptas) to the XML Type Library and leave it out from SOAP. As
> maps, ptas could be even accepted as a de-facto standard risen
> from the interop activities.

Again, agreed 100%.

>  So yes, removing ptas from SOAP Encoding is a viable solution,
> after all. I think I can propose that as a counterproposal to my
> original proposal (ooops, too much proposing here). It means
> making array serialization rules about half as complex with no
> philosophical issues.

***YES!*** Exactly what I had in mind. Keep the spec simple with
absolutely no loss of power. You just do p-t-a's differently.
You can still do them (like your example above), but all sorts
of confusing and complex stuff is removed from the base spec.

> It does not affect the resolution of issue
> 161 and the issue 117 would be automatically closed.
>  If this passes, the credit should go to Alan for being stubborn
> in the right way. 8-)
> 
>                    Jacek Kopecky
> 
>                    Senior Architect, Systinet (formerly Idoox)
>                    http://www.systinet.com/

I don't care about credit. We support another protocol that I
think made a few similar mistakes (overly complex). The protocol never
took off as much as it could, and never achieved the level of
interoperability that should have been acheived. I want SOAP
to succeed. Its things like the current definition of p-t-a arrays
that I see as the greatest threat. If you dont get the basic
types correct, everything built on top is on shaky ground.
P-t-a arrays are useful. Sure. But keep the fundamental array
type simple, and build more complex types on top. That to me
is one of the many strengths of SOAP.

Alan

ps: Ok, I have finally managed to brainwash one other person, now just
the rest of the list! :-) :-) :-)

Received on Tuesday, 20 November 2001 19:09:24 UTC