- From: Asir S Vedamuthu <asirv@webmethods.com>
- Date: Tue, 13 Nov 2001 10:43:20 -0500
- To: "Jacek Kopecky" <jacek@systinet.com>
- Cc: "'Xml-Dist-App@W3. Org'" <xml-dist-app@w3.org>
My choice is two-state sparse arrays. I am an implementer and I built this very easily. > Asir, IMHO the problem of two-state and three-state values > is not only in arrays I am OK with the general rule in Section 4.1 rule #9. In this specific case, sparse arrays, I suggest that we restrict this rule to two-state. Regards, Asir ----- Original Message ----- From: "Jacek Kopecky" <jacek@systinet.com> To: "Asir S Vedamuthu" <asirv@webmethods.com> Cc: "'Xml-Dist-App@W3. Org'" <xml-dist-app@w3.org> Sent: Tuesday, November 13, 2001 10:16 AM Subject: Re: Summary: Sparse Arrays Asir, IMHO the problem of two-state and three-state values is not only in arrays. The current editor's copy says: section 4.1 rule #9: "A NULL value or a default value MAY be represented by omission of the accessor element. A NULL value MAY also be indicated by an accessor element containing the attribute xsi:nil with value "1 or true" or possibly other application-dependent attributes and values." section 4.5 "An omitted accessor element implies either a default value or that no value is known. [more on the meaning of the default value]" It seems that if 4.5 means "default value" as, for example, "+1" in the international phone number prefix (an application-defined default), then the two texts above don't distinguish between a NULL value and a default value. If we go further down this road, we'd end up with two-state arrays with application specifying what the omitted elements mean. I wonder if the RPC rule that the result accessor MUST be present in case of non-void methods returning NULL shouldn't go away in this case since the response is a struct. If, on the other hand, we want to have three-state arrays, we should remove the two cited texts and always take omission as something other than NULL. This means taking NULLs as first-class values for every nillable type (XML Schema allows every element to be marked as nillable). I myself prefer the first approach with two-state arrays and NULLs being equivalent with defaults and omitted accessors being equivalent with xsi:nil="true". Jacek Kopecky Senior Architect, Systinet (formerly Idoox) http://www.systinet.com/ On Tue, 13 Nov 2001, Asir S Vedamuthu wrote: > This is a summary of the sparse array thread [1] from September 2001 > archive. > > Points raised on sparse arrays are, > > (a) Sparse arrays maintain three states for every slot in an array: value, > nil and absent. Spare arrays have multiple representations with positions > and offsets. > > These make implementation painful. There were several rebuttals and follow > ups, > > (a-1) omitting an accessor and xsi:nil='true' are equivalent; did not > encounter any problems with implementing sparse arrays > > (a-2) omitting an accessor and xsi:nil='true' MAY or MAY NOT be equivalent > and it depends on implementations. Some commentators agree on this notion of > deferring semantics to the apps. > > (a-3) Some commentators disagree on the notion of deferring semantics to the > apps 'cos this is a pain for generic apps. Different interpretations lead to > bad interoperability. > > (a-4) Sparse arrays may be two-state or three-state. This depends on the > implementation. Three-state is complicated. Allowing two- or three-state is > complicated. > > (a-5) Full blown (two- or three-state) sparse array is complicated. Emerging > proposal is to limit sparse arrays to two-state arrays and rule out > three-state arrays. > > > (b) A desire to have a meta level mechanism to indicate sparse array and > specify the semantics of omitted accessors, say in WSDL. Such as, array is > sparse, array is never sparse, array may be sparse; if array is sparse, then > omitted accessor means nil or absent. In the absence of this mechanism, > every array is a potential sparse array. > > > (c) One commentator observed that sparse arrays aren't widely used. Other > folks said, there are certain apps that may benefit from it. It is nice to > have a standard way to represent spare arrays. > > > (d) Call to specify the representation for sparse arrays in SOAP Encoding as > unambiguous as possible. But, it is hard to define it precisely. > > > Proposed Actions > > [Action-1] Per (a), acknowledge one SOAP Encoding issue: clarify the scope > of sparse array, two-state, three-state or both. > > [Action-2] Per (b), this is a WSDL feature request. Forward this request to > the to be formed Web Services Description Working Group or request Alan Kent > to forward this request to the to be formed Web Services Description Working > Group or take this to the to be formed Web Services Coordination Group. > > [Action-3] Per (c), no action is necessary > > [Action-4] Per (d), this is an editorial request and [Action-1] will > determine the nature of this work for editors. I suggest that we make this a > subsidiary question to [Action-1] > > [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Sep/0001.htm > > Regards, > > Asir S Vedamuthu > > webMethods, Inc. > 703-460-2513 or asirv@webmethods.com > http://www.webmethods.com/ > > > >
Received on Tuesday, 13 November 2001 10:42:45 UTC