Re: updated proposal on issue #144 - array metadata in SOAP Encod ing

> > Why say 'types are good' and then say 'indicating sparseness is not
> > necessary'?
> 
> I don't hold that position.  It is only because of the fragility of
> current implementations, I believe, that typing is dominant.  Once we
> get dedicated clients talking to dedicated servers then typing should
> melt away.

I think there is another camp that believes exactly the opposite.
Wasn't there a recent thread that basically was saying 'people should
depend purely on types on the wire and not use WSDL files so truely
dynamic web applications and scripting languages can be used together.'
I disagree with the above statement, but certainly some people believe it.
I think the issue was if you have a dynamically typed scripting langauge
where everything is an object and operators make a guess as to the
type (if its all digits, it must be an integer!).

> It's only because right now we're generally doing things
> with all-purposes clients and servers, and we want to debug our
> implementations, that typing is included.

Some people I think want this to be the norm (because they are
using dynamically typed scripting languages). I do not belong
to this camp myself.

> Sparseness isn't a type, it's
> an attribute of data that an application CAN feed to its SOAP library so
> that a data-transfer optimization *that the application on the other
> side is expecting* can be performed.
> 	/r$

To me sparseness/partial-tranmission/whatever does change the way
values are encoded for transmission. There are extra things you
need to support. Some people in the past on this list have said
that a server does not have to support the sparse encoding form.
To me this means sparse arrays *should* be separate type to avoid
interop problems.

I think a fundamental part of the problem is actually SOAP does not
say what omitting a value in an array means - and for interoperability,
this is very important. Both ends must agree what it means or else
the two ends are not interoperable.

Alan

Received on Wednesday, 14 November 2001 22:36:49 UTC