Re: Summary: Sparse Arrays

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