W3C home > Mailing lists > Public > xml-dist-app@w3.org > December 2001

Re: Encoding: multistructs, generic compound types

From: Jacek Kopecky <jacek@systinet.com>
Date: Wed, 19 Dec 2001 13:53:37 +0100 (CET)
To: <xml-dist-app@w3.org>
Message-ID: <Pine.LNX.4.33.0112191351540.32456-100000@mail.idoox.com>
 Just for the record, as Pete has already noticed, I have no
desire to keep partially transmitted arrays, I'm one of the
proponents of removing them. 8-)
 I agree with your points completely, Pete.

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)

On Tue, 18 Dec 2001, Pete Hendry wrote:

 > >  Multistructs can be modeled as structs with some members being
 > > arrays, and that is IMO a very natural way of representing data
 > > structures, which can contain more than one value under one
 > > accessor.
 > >  Therefore I propose we remove the part of section 4.4.3 from the
 > > second paragraph till the end of the section. The first paragraph
 > > should stay, I think.
 > >
 > I would agree with this as it does not map easily. We
 > support multistructs by using arrays. However, I think this
 > argument should also be applied to sparse arrays. They
 > could be implemented using structs of key/values and so do
 > not need to be represented explicitely as they are
 > currently (and it would be a lot easier to agree on the
 > format if they were represented in this way!).
 > Also, when using a mixture of literal and section 5, a
 > struct in literal with an array looks like a multistruct in
 > section 5. This can be confusing.
 > Your argument is valid but goes against your desire to keep
 > sparse arrays! They do not map to any programming language
 > I know of and removing them does not remove any
 > functionality from SOAP (as the application level can
 > achieve the same).
 > I would also like to drop multistructs as I don't think
 > they provide anything that structs and arrays together
 > don't already provide.
 > Pete
Received on Wednesday, 19 December 2001 07:53:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:17 UTC