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

 Alan,
 personally I agree with you that in-spec two-state arrays might
be the right way to proceed.
 On the other hand, when we discussed the issue in the ETF, there
was an equally strong push in the direction of "omitted may mean
leave the current value in there, nil is a nil".
 This latter opinion is seemingly based on viewing nils as
first-class values, a view which I (and probably you, Alan, as
well) don't share.
 On the other hand it doesn't seem to me that the implementation
is so much more difficult. As I kept pointing out in the
discussions, it's ultimately the application who "knows" and it
can signal to the implementation how arrays are to be treated.
 We don't provide means of signaling that an array is in fact
fully transmitted before the whole array is read in so
effectively we don't distinguish between PTAs and normal arrays.
 Alan, can you please provide examples of the difficulties in
handling three-state arrays? Our implementation, WASP, does allow
handling arrays as three-state (otherwise defaulting to nils on
omitted elements) and it's the application that gets to decide.
 Considering all these discussions it seems to me that this
direction for SOAP arrays is the one that least people (but not
nobody) will have issues with. 8-)
 Oh well. 8-)

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Tue, 20 Nov 2001, Alan Kent wrote:

 > On Tue, Nov 20, 2001 at 04:03:51AM +0100, Jacek Kopecky wrote:
 > >  4) added a paragraph to 4.4.2.1 stating that the meaning of
 > > untransmitted members in partially transmitted arrays is
 > > application and implementation specific.
 >
 > 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.
 >
 > 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.
 >
 > This can be done, but is not efficient and makes the toolkit APIs
 > very messy for what I claim will give benefit to very few real
 > life applications. Worse, the spec says a protocol implementation
 > is allowed to translate an omitted value into null, meaning
 > any application using that toolkit may fail to interoperate
 > with another application using a different toolkit.
 >
 >
 > I personally would like to see p-t-a/sparseness disappear completely.
 > But that is not going to happen I suspect.
 >
 >
 > How about at least improving the world and saying something like
 > 'omitted elements in an array is the same as that element having
 > a null value' and 'it is up to an application to decide how to
 > treat null values.'
 >
 > That is, using xsi:nil="1" is identical to omitting
 > the array value using position/offset. This is much easier to
 > implement in toolkits (many languages have a null pointer concept).
 > Toolkits are responsible for handing over a consistent data type
 > to applications. The interpretation of that data type is application
 > specific.
 >
 > I do not believe a SOAP toolkit implementation should
 > be permitted to apply interpretation to a SOAP message.
 > I think interpretation should be completely an application concept.
 > I think my above proposed change in direction means there is
 > a clear definition of what a toolkit implementation should do,
 > while leaving a degree of interpretation up to the application.
 >
 > Eg: for the SOAP interop tests, we let all the arrays may contain
 > nulls. The "application" logic is to echo what is received straight
 > back. Without this, array interoperability testing is (well if
 > I send a p-t-a with an ommitted value in it, don't check what
 > comes back as anything what-so-ever is acceptable). Yuck.
 >
 > Further, XML Schemas can define is legal for an element to be nil or
 > not (the nillable attribute), so I assume it can be defined using
 > XML schema whether values in an array can be nil or not. This
 > gives, for example, a toolkit processing a WSDL file generating
 > C/C++ the option of using an array of integers or an array of
 > pointers to integers. If the array type does not allow null
 > values in the array, then if a value is omitted, its a fault.
 > Offset/position values can still be used, but as long as all
 > slots in the array are populated.
 >
 >
 > If the above is not done, then if you are saying a major reason
 > for having p-t-a arrays is that the full array may be very large
 > and you want to reduce the data on the wire, then implemntations
 > should really also worry about the size of the in-memory data
 > structure representing the array. To provide a consitent API to
 > applications, this means that all arrays must not be bound
 > directly to the programming languages native array type - the SOAP
 > toolkit must implement its own array type allowing omitted values
 > to be efficiently represented in memory. This is certainly possible,
 > but very ugly (in my opinion).
 >
 >
 > So I strongly put forward that omitted values in arrays (and omitted
 > parts of responses) be explicity stated as being the same as nil
 > in the SOAP standard. It is *purely* an application concept what
 > the interpretation of a nil is (just as its an application concept
 > of what any other valid valid means). But as soon as you say
 > "here is how you encode something which we explicity do not define
 > what it means" then that concept is by definition not interoperable
 > within the spec. You must come to agreements outside of the spec.
 > So a secondary specification or agreement is needed in order
 > to define interoperability. Yuck.
 >
 > With the current proposal I think the only satisfactory implementation
 > of arrays is to support three states per array element (omitted,
 > nil, or contains a valid value). If most protocol implementations
 > treat omitted values as null, then applications get no benefit
 > from the 'ommitted' concept so carefully introduced. Since this
 > is already the norm, I vote 'omitted values are identical to
 > null values'.
 >
 > Ok, I am starting to rave. I will stop.
 >
 > Alan
 >

Received on Tuesday, 20 November 2001 03:41:11 UTC