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

> 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.

> The reality is SOAP toolkits are built to handle the SOAP spec.
> If the toolkit implements the semantics, then the application
> does not get a choice. If the application wants implements the
> semantics, then the toolkit must support 3 states for each slot
> in all arrays: null, omitted, or a real value.

The SOAP toolkit cannot completely implement the semantics, and it never
could -- too much meta-data (datatype) information was *always* required
for the "just-SOAP" library to be able to properly implement
everything.  It could make its own decisions, or it could require type
information (XSD or what have you) to help decide, or it could require
the application to completely specify things.  SOAP encoding is not TCP,
it is data serialization, and there are times when serious
application-provided information is needed.  There's just no way around

> 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.
Zolera Systems, Your Key to Online Integrity
Securing Web services: XML, SOAP, Dig-sig, Encryption

Received on Tuesday, 20 November 2001 09:36:48 UTC