- From: Jacek Kopecky <jacek@systinet.com>
- Date: Tue, 18 Dec 2001 01:49:39 +0100 (CET)
- To: Pete Hendry <peter.hendry@capeclear.com>
- cc: <xml-dist-app@w3.org>
Pete, 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. 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. Now in XMLP WG we're working on a protocol for messaging in XML, and we accepted SOAP as our base that needs some tweaking resulting in the experience we've gained with it, just like some chemistry WG can work on an XML language for chemical documents, based on one or a few existing chemical languages. This is GOOD(tm), but let's not try to do too much. Already some people feel RPC and encoding is too much. If we simplify the RPC and Encoding and if we make explicit the optionality thereof, it might become clear that we think that the core value of our work is the SOAP messaging, not Encoding nor RPC, though these might (and will, guaranteed) be useful. 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. 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? And if we say "it can go into a separate section, building on the Encoding", the XMLP WG has a response: It's out of scope of _XML_Protocol_. 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-) Best regards, Jacek Kopecky Senior Architect, Systinet (formerly Idoox) http://www.systinet.com/ On Mon, 17 Dec 2001, Pete Hendry wrote: > > One datatype that soap does not currently have is the concept of a NameValue list (KeyValue list, Map, Hash, etc). > Vendors are defining their own (such as Apache) and hoping that others will use them so that they can interoperate. > However, since this name/value concept is suported as standard in just about every programming language I think it > should be a candidate for a data type in SOAP. > > Apache defines the notion of a Map of Pairs. I would like to use the more general NameValue and NameValueList > definitions with which a Map can be represented. > > > <complexType name="NameValue"> > <sequence> > <element name="name" type="xsd:anyType" /> > <element name="value" type"xsd:anyType" nillable="true" /> > </sequence> > </complexType> > > <complexType name="NameValueList"> > <complexContent> > <restriction base="SOAP-ENC:Array"> > <sequence> > <element name="nv" type="xsd1:NameValue" > minOccurs="0" maxOccurs="unbounded" > nillable="true" /> > </sequence> > <attribute ref="SOAP-ENC:arrayType" wsdl:arrayType="xsd1:NameValue[]" /> > </restriction> > </complexContent> > </complexType> > > In the Java community this would preempt JSRs such as JAX-RPC creating their own mappings which may not be agreed by the > non-java community and interop breaks down. > > Pete >
Received on Monday, 17 December 2001 19:49:57 UTC