- From: Andrew Layman <andrewl@microsoft.com>
- Date: Thu, 20 Sep 2001 11:34:59 -0700
- To: "Jacek Kopecky" <jacek@idoox.com>, "Alan Kent" <ajk@mds.rmit.edu.au>
- Cc: "SOAP" <xml-dist-app@w3.org>
Per the spec, omitting an accessor and having it with xsi:nil="true" MAY or MAY NOT be equivalent. The spec leave open all possibilities. Some implementations of structure serialization evidently choose to treat them as equivalent representations, but neither the SOAP nor the XML Schemas specification requires this. -----Original Message----- From: Jacek Kopecky [mailto:jacek@idoox.com] Sent: Thursday, September 20, 2001 5:52 AM To: Alan Kent Cc: SOAP Subject: Re: sparse arrays - too complex? Alan, I disagree that there are three states for array values. In structures, omitting an accessor and having it with xsi:nil="true" is equivalent. I see sparse arrays as exactly the same for arrays where you cannot just omit an item to make it nil. This is also how we implement sparse arrays - putting NULLs where the item is not present. We optionally generate sparse arrays when the array that is being serialized contains NULLs. You can easily represent a SOAP array of ints as C++ array of pointers to ints so I don't see why nillable content adds trouble. We have implemented it with no problems coming from sparse array support. Every discussion about nils and nothings seems to be endless, though. 8-) Jacek Kopecky Idoox http://www.idoox.com/ On Mon, 3 Sep 2001, Alan Kent wrote: > I just finished typing up a carefully crafted question on soap arrays that > took an hour to compose. Then lost it. <:-( Here is a cut down version the > second time around. > > After finishing an implementation of SOAP, I have come to the *personal* > opinion that sparse arrays add a lot of complexity, slow down implementations > for no benefit to the majority of applications. > > There is also a discussion on the interoperability list now going on > to which the response seems to be that every slot in an array can > be one of three states: hold a value, be nil, or not be present > (which is different to nil). > > This three state logic makes implementation of library code painful. > > To me sparse arrays are useful only a small percentage of the time and > so should be removed from the low level SOAP protocol and moved to the > layer built on top. For example, use an array of complexType with > two elements - one for the key, and one for the value. > > An alternative is to allow a WSDL file somehow say that this array > is sparse (with the default being the array must not be encoded using > the sparse representation). > > At present *all* arrays could be encoded using the different sparse > representation with positions and offsets. This means that all libraries > have to worry about this complexity. > > Alan > > ps: I have similar concerns about nil values (for example, you cannot > decode a C++ array of int's as the array may have a nil in it) and > href=. In both cases every element being decoded has to perform additional > checks, which adds up if performance is a concern. >
Received on Thursday, 20 September 2001 14:36:11 UTC