- From: Alan Kent <ajk@mds.rmit.edu.au>
- Date: Wed, 21 Nov 2001 10:45:48 +1100
- To: xml-dist-app@w3.org
On Tue, Nov 20, 2001 at 02:00:11PM -0800, Andrew Layman wrote: > Maybe I am missing something, in which case I beg forgiveness, but I am > puzzled. I thought that a Java array declared as Integer[] could easily > allow null elements. That was my point. It can hold null elements. But it cannot represent omitted elements as well. My point was that 3-states per slot cannot use native types, but two states (null/valid-value) can use native types more readily. > Whether the receipt of a sparse array sets the omitted elements to null > or leaves them untouched is not a matter of the array encoding itself, > but of the semantics of the message in which the array appears. That > is, some messages may have CREATE semantics and others UPDATE semantics. > This is not surprising, any more than that a number such as "100" has > context-dependent meaning. In some messages it might mean "set my bank > balance to 100" and in others it could mean "add 100 to my bank > balance". I agree with your statements. They describe potential uses for partially transmitted arrays. But a SOAP toolkit does not know what the application semantics are. A toolkit should capture the exact information of what was on the wire for SOAP to make it all available to the application to apply such semantics. But the SOAP spec says its "implementation or application specific". Toolkits therefore are implementing p-t-a array omitted values as nulls, as default values (eg: 0 for integers), or by having 3-states per element using more complex types. Implementations exist now for all three variations. These implementations are all valid according to the spec. Yuck. And worse, if the SOAP toolkit does not implement 3-states per slot, the application cannot implement your desired semantics because it is not told about which slots are omitted. Double yuck. Alan
Received on Tuesday, 20 November 2001 18:46:21 UTC