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

On Tue, Nov 20, 2001 at 09:36:19AM -0500, Rich Salz wrote:
> > I probably sound like a broken record, but I personally feel its bad
> > for interoperability for a spec to define a concept and then say
> > 'but its application specific.' The spec should completely
> > define what is within the scope of the spec and not specify
> > anything that is not within scope of the spec.
> 
> No, it's a good thing.  It gives application builders a handle on how to
> do something they might need to do.  It can be confusing that three
> common cases are boiled down into one wire-level construct, but since
> those cases are non-overlapping, it actually *simplifies* the work of
> the SOAP implementor.

I think there is a valid point here in that if three different
constructs can be encoded one way, you only have to support one way. 

However :-), if it means that all toolkits *must* support the most
complex way because there is no differentiation, I think this is
a bad thing. With my developer's hat on, I would like to see
toolkits use types as friendly to my programming language as possible.
If I want to send/receive an array of integers, I would like to declare
an array and pass it to the stub function provided by the library.
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.

Yes its doable, I just think in practice its very ugly. So ugly
that at least some toolkit implementors wont do it (and are not
required to do so by the current spec). I think SOAP encoded
arrays should be kept simple. I think higher levels of semantics
are useful, but should be encoded into the data structures being
sent rather then encoded into the base SOAP protocol. (See a
separate mail item for more details.)

> > the spec says a protocol implementation
> > is allowed to translate an omitted value into null
> 
> Actually, it seems to me that the spec is very careful to talk about
> application semantics, and not protocol implementations per se.
> 	/r$

I guess it depends how you interpret the phrase "implementation
or application specific". My reading of this was 'implementation'
is different to 'application', so I assumed 'implementation' could
validly (according to the spec) be interpreted toolkit implementation.

Alan

Received on Tuesday, 20 November 2001 18:54:49 UTC