W3C home > Mailing lists > Public > xml-dist-app@w3.org > November 2001

Re: counterproposal on issue #144

From: Alan Kent <ajk@mds.rmit.edu.au>
Date: Wed, 21 Nov 2001 11:08:51 +1100
To: xml-dist-app@w3.org
Message-ID: <20011121110851.I564@io.mds.rmit.edu.au>
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.


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

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