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

Re: NameValue and NameValueList data types

From: Pete Hendry <peter.hendry@capeclear.com>
Date: Fri, 21 Dec 2001 00:29:14 +0000
Message-ID: <3C22825A.90704@capeclear.com>
To: Jacek Kopecky <jacek@systinet.com>
CC: xml-dist-app@w3.org
>  the WG has decided before that adding types is not the way to go
> in SOAP Encoding. There's actually an ongoing battle of some to
> remove some types, namely partial and sparse arrays.


I agree up to a point. Until the 'base' types are defined then adding types is Ok. It is defining what 'base' types are 
that is the challenge.

Before I go on, I'd like to change my proposal from NameValue to KeyValue since the key need not be a string.


>  As the Web has demonstrated, people can actually talk to each
> other in a simple and extensible environment for they will build
> extensions and if important, the de-facto standard will
> eventually appear. Obviously, XML is the ultimate in this
> direction.


Take away most of the types in XML-Schema and this will not change! However, types that are used frequently enough and 
are important enough to have a definition in (almost) every language should be considered for inclusion in the standard 
(not a de-facto standard).


>  Apache soapers have already shown that where maps are needed,
> they are specified, and others have demonstrated that they can
> accept the reasonable proposal by Apache. 


Some people support Apache maps, not all. I don't like the idea of referencing Apache schema each time I want a basic 
type such as KeyValue. It adds another dependency to our implementation which is not desirable (nothing against Apache 
here, we just need to minimise dependencies at such a low level).

> Taking your proposal to
> the extreme, do you think it would be good if the XMLP WG tried
> to specify every useful high-level data structure in its Encoding
> section? 


Taking your argument to the extreme, never add another type to SOAP even if it proves to be of immense value to everyone!

Looking at it another way, why not lobby the schema groups to have types such as int, short, etc. removed as we can all 
define these based on integer anyway? The reason they exist is that they are fundamental in (almost) every programming 
language, as is the concept of KeyValue (although gDay, etc. go against this argument :-) ).

>  Anyhow, if SOAP specified NameValueLists in a section separate
> from the Encoding, as I just suggested, IMHO partial and sparse
> arrays should go there, too. 8-)


I am not suggesting them in a separate section, I am suggesting they are a basic, core type. Take sparse arrays as an 
example. If they are dropped then how can they be simulated? The simplest answer (in my opinion) is as a list of 
KeyValue elements with the key being the position. But there is no KeyValue to use so different implementations will do 
their own thing, and perhaps eventually converge on one schema.

I would rather preempt this and define all basic types now. I think they are all there except KeyValue (I can't think of 
any others I have needed on a regular basis).

Pete
Received on Thursday, 20 December 2001 19:31:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 22:28:13 UTC