- From: Pete Hendry <peter.hendry@capeclear.com>
- Date: Fri, 21 Dec 2001 00:29:14 +0000
- 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