Re: latest proposal on issues #144 and #161 - array encoding

On Tue, Nov 20, 2001 at 10:07:58PM -0500, Rich Salz wrote:
> > But if SOAP toolkits are *required* to support the most complex
> > semantics of p-t-a for *all* arrays, then I cannot use my native
> > programming langauge array (the toolkit cannot differentiate
> > because they are the same). I have to build a toolkit specific
> > data structure up just for sending an array of integers.
> 
> No.  If you want to enable that kind of optimization, then you can
> provide an ADDITIONAL API for your customers to use.  And, on the
> receiving side, the other application will tell your toolkit "sparse
> coming"

I do not believe dynamic discovery of 'sparse coming' is acceptable.
That is, an application cannot change its code as an array arrives.
So there are clearly cases where the contents of messages must be
known in advance. A simple example is a WSDL compiler - the code
generated must either handle p-t-a's or not handle them.

It gets harder to argue a position because its not clear what the
current SOAP position is. p-t-a's are supported. Are p-t-a's
a different type to arrays without using 'offset' and 'position'?
Some say yes, some say no. There is no difference in the type
information in xsi:type attributes etc. There is no difference
in WSDL files. Yet they are an extension on simple arrays?
Or is there no such thing as a simple array (they are all p-t-a
semantically). The current spec is not clear on this matter.

> I mean, you must have some way for a receiving application to signal to
> your toolkit what it wants, otherwise when it sees
> 	<i>5</i>
> You don't know if it's integer, floating point, or string.

There are multiple ways of explaining my concern. At the crux I prefer
a standard to have the minimum required to support necessary functionality.
p-t-a's in my opinion do not need to be at the lowest protocol level.
They will not be commonly used. They can easily be implemented at a higher
level. SOAP does not try to capture all data types. It uses XML schema
for that. p-t-a's make the API to SOAP significantly more complex.
p-t-a's make the SOAP spec significantly more complex. SOAP does not
try to capture all data types in the core protocol. I guess I am
arguing that I do not believe the additonal complexity of putting them
into the *core* protocol is worth the benefit.

> Do you only handle typed messages?  That would help me understand your
> motivation...

I am not coming from the perspective of my SOAP implementation. I am
coming from a purely generic position. I worry about interoperability.
I think SOAP toolkits should support exactly what SOAP says. I think
as soon as a standard says "you encode it like this but its application
specific" then its bad news. The SOAP interoperability tests clearly
show that people are implementing p-t-a's differently in their SOAP
toolkits. This alone sets off alarm bells in my mind.

To me there are many issues to be clarified.
+ Are p-t-a's a different conceptual type to normal arrays?
+ If an application decrees that it will only accept complete arrays,
  is it wrong to send an array using offset and position attributes etc,
  where a value is supplied for every position (so the array is not parital)?
+ Since all other types (integer, string, etc) have a way of indicating
  that they are different to each other, why don't p-t-a's identify
  themselves differently to normal arrays?
+ Is it valid for a toolkit to say 'I will turn omitted values in to null'?
+ Is it a goal for SOAP to be efficient to implement or to simplify
  implementations?

So why do I spend so much effort of this?
- I like removing cruft.
- I like things being semantically clean.
- I *prefer* removing p-t-a's from the core SOAP protocol because they
  can be *easily* implemented using XML schema based data structures
  and 99% of applications using SOAP will not require p-t-a's.
- No one has ever explained why p-t-a's are more important in the core
  protocol than all the other data structures that have been left out.
- I like having an array type that corresponds to most modern programming
  language array types.
- I like having toolkits that bind tightly to programming language data
  types to avoid the good old data impedience problems and data conversions.

Basically I think the current position of the SOAP standard is
bad for interoperability, as currently being demonstrated in
the interoperability testing. p-t-a's sort of are the same but
sort of are different to normal arrays. Semantically, the best model
I can describe for SOAP is that *all* arrays are really p-t-a, its
just that some (most) instances have all the values present.

Ok, I am rambling on again. Bottom line: After all these discussions,
it is not clear to me still p-t-a's are a different semantic data
type to normal arrays. They are not given any different type information,
but they are encoded differently. Out-of-band agreements I think are
bad for interoperability, so I think it will be mistake in the long
term writing applications assuming they wont receive a p-t-a.
I think SOAP should support a simple array type where all values
are always present, guaranteed, no questions asked. There are many
possible ways to achieve this, but I think the current spec does not
achieve this.

Enough.
Alan

Received on Wednesday, 21 November 2001 00:54:02 UTC